Bug #15884
closedTime module fails to identify timezone correctly
Description
I think the following snippet is the best summary of the problem I could write:
irb(main):001:0> Time.new(2012, 12, 1).utc?
=> false
irb(main):002:0> Time.new(2012, 12, 1).zone == 'UTC'
=> true
Updated by wishdev (John Higgins) almost 5 years ago
I think this shows the logic behind what is occurring here.
On my system
Time.new(2002, 12, 1).zone
=> PST
(Time.new(2002, 12, 1) + 60 * 60 * 24 * 180).zone # Add 180 days
=> PDT
Time.new(2002, 12, 1).utc.zone
=> UTC
(Time.new(2002, 12, 1).utc + 60 * 60 * 24 * 180).zone # Add 180 days
=> UTC
The difference is that Time.new returns a local time zone stamped time - which is subject to change at the whim of the local authority. When you use either Time.utc or Time.new.utc you end up with a locked UTC time which will not change based on what day of the year it is.
So that Dec 1st, 2012 may have fallen into the UTC time zone on your local system - it does not mean that it is a UTC time - it is a UTC at the exact moment you checked but subject to change.
I believe that the current behavior is much better because it ensures you are using an exact concept as opposed to something that is time of year/locality dependent. If you want UTC time - then ensure you have UTC time with either Time.utc or friends.
Updated by Anonymous almost 5 years ago
Thanks for such a good explanation John! What you said makes perfect sense so I'm happy to close this as "invalid", or whatever is the most appropriate status. Unfortunately, I don't seem to be able to update the Status on this ticket.
Updated by jeremyevans0 (Jeremy Evans) almost 5 years ago
- Status changed from Open to Rejected