[Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

>>> If there are not, maybe the intended semantics should go
>> > by the wayside and be replaced by what pytz does.

>> Changing anything about default arithmetic behavior is not a
>> possibility.  This has been beaten to death multiple times on this
>> mailing list already, and I'm not volunteering for another round of it
>> ;-)


[Alex]
> Tim and Guido only grudgingly accept it, but datetime already gives you "the
> pytz way" and PEP 495 makes a small improvement to it.

To be clear, "Tim and Guido" have nothing at all against timeline
arithmetic.  Sometimes it's exactly what you need.  But the _intended_
way to get it was always to convert to UTC first, or to just use plain
old timestamps.  Classic arithmetic was very intentionally the
default.

The only "grudgingly accepted" part is that .astimezone() grew a
special case later, to make the absence of an argument "mean
something":


> The localize/normalize functionality is provided by the .astimezone()
> method which when called without arguments will attach an appropriate
> fixed offset timezone to a datetime object.   You can then add timedeltas
> to the result and stay within a "fictitious" fixed offset timezone that extends
> indefinitely in both directions.  To get back to the actual civil time - you
> call .astimezone() again.  This gives you what we call here a "timeline"
> arithmetic and occasionally it is preferable to doing arithmetic in UTC.
> (Effectively you do arithmetic in local standard time instead of UTC.)
> Using a fixed offset timezone other than UTC for timeline arithmetic is
> preferable in timezones that are far enough from UTC that business hours
> straddle UTC midnight.

The distance from UTC can't make any difference to the end result,
although if you're working in an interactive shell "it's nice" to see
intermediate results near current wall-clock time.

"A potential problem" with .astimezone()'s default is that it _does_
create a fixed-offset zone.  It's not at all obvious that it should do
so.  First time I saw it, my initial _expectation_ was that it
"obviously" created a hybrid tzinfo reflecting the system zone's
actual daylight rules, as various "tzlocal" implementations outside of
Python do.