working around frozen hash

D

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

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
 
R

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
 
D

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
 
D

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,818
Messages
2,569,727
Members
45,664
Latest member
Phil79581

Latest Threads

Top