Issue #15884 has been updated by wishdev (John Higgins).


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.


----------------------------------------
Bug #15884: Time module fails to identify timezone correctly
https://bugs.ruby-lang.org/issues/15884#change-78257

* Author: UmkaDK (Dmytro Konstantinov)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
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
```



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>