Project

General

Profile

Actions

Bug #15884

closed

Time module fails to identify timezone correctly

Added by Anonymous almost 5 years ago. Updated almost 5 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
ruby -v:
ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]
[ruby-core:92878]

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.

Actions #3

Updated by jeremyevans0 (Jeremy Evans) almost 5 years ago

  • Status changed from Open to Rejected
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0