Project

General

Profile

Bug #15884

Time module fails to identify timezone correctly

Added by UmkaDK (Dmytro Konstantinov) 7 months ago. Updated 7 months ago.

Status:
Rejected
Priority:
Normal
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

History

Updated by wishdev (John Higgins) 7 months 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 UmkaDK (Dmytro Konstantinov) 7 months 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.

#3

Updated by jeremyevans0 (Jeremy Evans) 7 months ago

  • Status changed from Open to Rejected

Also available in: Atom PDF