[ruby-core:87703] [Ruby trunk Bug#14879] Time#+ and Time#- do not preserve receiver's utc_offset if ENV['TZ'] is modified after receiver is created

Issue #14879 has been updated by ioquatix (Samuel Williams).


> In your case you may want NZST and NZDT.

Expecting users to know the time zone in advance is not feasible. User should be able to say "This date, time at this location" and it computes the correct offset. Anyway, it's a separate issue.

> Your example results are due to the fact that you are changing ENV['TZ'] after creating the Time instance, which affects new time instances, and (time + 1) creates a new Time instance.

Yes that is what I suspected.

> I think it is unreasonable to expect Time#+ and Time#- to have special handling for the case where ENV['TZ'] is modified after the Time instance is created, but I'll admit that it is subjective whether the methods should preserve the receiver's utc_offset in such cases. I would say it shouldn't be expected, because Time#+ and Time#- modifies utc_offset when crossing DST boundaries, and keeping the same utc_offset would lead to undesired behavior.

I think there are two separate cases you discuss. The first one being whether `Time#+/-` should retain the `utc_offset`, and whether `Time#+/-` should be able to change `utc_offset` when going cross DST changes. You've used the second case to argue against the first.

I think the 1st case is a bug.

I think the 2nd case is almost a bug but in theory is reasonable behaviour.

The problem is, `-0700` is a offset from UTC, and doesn't encode enough information to relate to DST rules AFAIK. Let's use Canada as an example. Some areas are -7 hours all year around, other areas use -6 hours for DST. So, how do you know enough information what case it is, considering you only have `-0700`? (https://en.wikipedia.org/wiki/Time_in_Canada)

So, I'd be interested to know where those DST rules are coming from, because that stuff is hard to encode, subject to the whims of governments, and changes at the drop of a vote.

Coming back to the bug report, I don't think adding/subtracting seconds should change the `utc_offset`, unless the user has actually specified a physical time zone on which DST rules are known (e.g. "Pacific/Auckland") and the new time crosses a DST boundary which affects the `utc_offset`. Every other case where the UTC offset changes, I'd assert, is a bug.

----------------------------------------
Bug #14879: Time#+ and Time#- do not preserve receiver's utc_offset if ENV['TZ'] is modified after receiver is created
https://bugs.ruby-lang.org/issues/14879#change-72726

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
I have been having some problems with `Time`. When I add or subtract seconds, sometimes the utc_offset is changed unexpectedly.

```
$ ruby -e 'require "time"; puts Time.parse("5pm NZT")'            
2018-06-29 17:00:00 +1200

$ ruby -e 'require "time"; puts Time.parse("5pm NZT") + 1'
2018-06-29 17:00:01 +1200

$ TZ=UTC ruby -e 'require "time"; puts Time.parse("5pm NZT") + 1'
2018-06-29 17:00:01 +0000
```

This seems like strange behaviour. The `utc_offset` shouldn't change IMHO.



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

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