working around frozen hash

[Dany]

I need to parse the following date string (part of a file I need to
parse)

irb(main):001:0> date='Fri Jun 20 02:32:28 GST 2008'
=> "Fri Jun 20 02:32:28 GST 2008"

It seems like the DateTime parsing handles GST as Guam Standard time
UTC+10

irb(main):002:0> require 'date'
=> true
irb(main):003:0> DateTime.parse(date).zone
=> "+10:00"

In my case, GST is Gulf Standard Time UTC+4

My thought for a 'quick' workaround fix, was to modify the value in
the library/moduel

irb(main):004:0> puts Date::Format::ZONES['gst']
36000
=> nil
irb(main):005:0> Date::Format::ZONES['gst'] = 4*3600
TypeError: can't modify frozen hash
from (irb):5:in `[]='
from (irb):5

But as the output shows, the value is 'frozen' in that library. I am
looking for ideas how to workaround my issue. Any help appreciated.
BTW, I'm not a programmer and I have not done much with Ruby, yet.

Thanks,
Dany

 

[F. Senault]

Le 30 juin à 20:12, Dany a écrit :

But as the output shows, the value is 'frozen' in that library. I am
looking for ideas how to workaround my issue. Any help appreciated.
BTW, I'm not a programmer and I have not done much with Ruby, yet.

Why don't you change the timezone in the sting beforehand ?

Something like :
=> "+04:00"

Of course, if you need to pase many dates at many points, you can either
redefine your own parsing routine (def DateTime.myparse(...)), or even
patch the DateTime.parse function with via alias and a new definition...

The only relative downside is that it will be a bit slower.

Fred

 

[Robert Dober]

<snip>i
Date::Format::ZONES = Date::Format::ZONES.dup # ignore warning
Date::Format::ZONES['gst']= 42 * 343 - 42 /7
Date::Format::ZONES.freeze

That should do the trick
HTH
Robert

 

[Dany]

Why don't you change the timezone in the sting beforehand ?

Something like :


=> "Fri Jun 20 02:32:28 GST 2008">> DateTime.parse(date.gsub(' GST ', ' UTC+04 ')).zone

=> "+04:00"

Because that is too easy and makes too much sense ;-) I did not know
about UTC+04 format. That is simple and easy to understand what is
going on. I am not too concern with performance, at this point.
Thanks!

Of course, if you need to pase many dates at many points, you can either
redefine your own parsing routine (def DateTime.myparse(...)), or even
patch the DateTime.parse function with via alias and a new definition...

My thoughts were going into that direction... but I burned myself
going down a similar path for another 'library' before. I didn't
understand enough what I was 'patching' and my fix only cover some
specific cases, for me, but broke other.... I also don't like to mess
around with any code related to time and date. I thought my idea of
just changing a 'constant' in the library, was the less 'intrusive'
way to not change any code 'logic'.

Thanks again
Dany

 

[Dany]

Date::Format::ZONES = Date::Format::ZONES.dup # ignore warning
Date::Format::ZONES['gst']= 42 * 343 - 42 /7
Date::Format::ZONES.freeze>

Awesome. I was expecting a way to 'workaround' the freeze. Trying to
understand what is going.. I can't 'unfreeze' the hash/object, but I
can 're-assign' a constant (hence the warning).. So you assign the
original constant to new object/Hash which is a copy of the original
(dup). You can then change the value of interext and 're-freeze' (for
good measure).

Probably don't have the accurate terminology but hope I got the idea.
Thanks a lot!
Dany

 

[Robert Dober]

I believe that you described the process very well .
Robert