Hi
I must be slipping, but say I have a string that looks like:
3/11/2012 2:50:00 AM
If I use the UTC timezone and ask it to parse this time, what would you
expect the result to be? Personally, I’d say
3/11/2012 2:50:00 AM UTC
Given this is the DST switchover date (for some places) this is an edge
case. It’s the “spring forward” rule so 2:50 AM is 3:50… But not in
UTC… that’s one of the nice things about UTC. So, I was surprised
when:
ActiveSupport::TimeZone[“UTC”].parse(“3/11/2012 2:50:00 AM”) => Sun, 11
Mar 2012 03:50:00 UTC +00:00
Ok, maybe the AM trips it up into thinking I’m not really UTC because
I’m
not using a 24 clock? Nope:
ActiveSupport::TimeZone[“UTC”].parse(“3/11/2012 2:50:00”) => Sun, 11
Mar
2012 03:50:00 UTC +00:00
But, if I append " UTC" to the string it works as I expect:
ActiveSupport::TimeZone[“UTC”].parse(“3/11/2012 2:50:00 UTC”) => Sun, 11
Mar 2012 02:50:00 UTC +00:00
ActiveSupport::TimeZone[“UTC”].parse(“3/11/2012 2:50:00 AM UTC”) => Sun,
11
Mar 2012 02:50:00 UTC +00:00
I looked at the documentation and parse for AR:TZ takes two parameters,
the
second being a “now” that:
If upper components are missing from the string, they are supplied from
#nowhttp://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-now
So, I tried passing in a UTC current time, but it also went back to
3:50:
ActiveSupport::TimeZone[“UTC”].parse(“3/11/2012 2:50:00”,
ActiveSupport::TimeZone[“UTC”].now) => Sun, 11 Mar 2012 03:50:00 UTC
+00:00
For reference, I’m using:
tzinfo 0.3.33
activesupport 3.2.6
Am I being stupid here? A cursory googling led to
The wontfix is indicative, but maybe this should at least be a gotcha in
the documentation? Again, apologies if I’m being dense and have missed
something obvious.
Thanks,
Andrew