Path: csiph.com!news.swapon.de!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
MIME-Version: 1.0
In-Reply-To: <m2h9mzqyy7.fsf@fastmail.com>
References: <m2h9mzqyy7.fsf@fastmail.com>
From: Tim Peters <tim.peters@gmail.com>
Date: Sat, 12 Sep 2015 13:53:06 -0500
Subject: Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
To: Random832 <random832@fastmail.com>
Cc: datetime-sig <datetime-sig@python.org>, Python-List <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.437.1442084009.8327.python-list@python.org>
Lines: 50
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96448

> I was trying to find out how arithmetic on aware datetimes is "supposed
> to" work, and tested with pytz. When I posted asking why it behaves this
> way I was told that pytz doesn't behave correctly according to the way
> the API was designed.

You were told (by me) that its implementation of tzinfos was not the
_intended_ way.  Which is another way of saying it was an
unanticipated way.  "Correctly" is a whole different kind of judgment.
pytz users who faithfully follow the docs seem happy with it.


> The tzlocal module, on the other hand, appears to
> simply defer to pytz on Unix systems.
>
> My question is, _are_ there any correct reference implementations that
> demonstrate the proper behavior in the presence of a timezone that has
> daylight saving time transitions?

Which specific "proper behaviors"?  :"Hybrid" tzinfos following the
recommendations in the Python docs, including the sample
implementations in the docs, correctly mimic local clock behavior
(skipping the clock ahead when DST starts, and moving the clock back
when DST ends) when converting from UTC.  It's impossible now to do
local -> UTC conversions correctly in all cases, because it's
impossible now to know which UTC time was intended for a local time in
a fold.  For the same reason, it's impossible now to know whether a
local time in a fold is intended to be viewed as being in daylight
time or standard time.

But do note limitations of the default .fromutc() implementation:  it
only guarantees correct mimic-the-local-clock behavior when
total-offset transitions are solely due to a notion of "daylight time"
that strictly alternates between .dst() returning zero and non-zero
values.

Transitions due to any other reason may or may not be reflected in
.fromutc()'s treatment of the local clock.  Most importantly, a
transition due to a zone changing its base ("standard") UTC offset is
a possibility the default .fromutc() knows nothing about.

The wrapping of the IANA ("Olson") zoneinfo database in dateutil uses
hybrid tzinfos (the intended way of wrapping zones with multiple UTC
offsets), and inherits the default .fromutc(), so all the above
applies to it.

Including all behaviors stemming from the impossibility of
disambiguating local times in a fold.  That's not a bug in dateutil.
It's a gap in datetime's design,  It was an intentional gap at the
time, but that pytz went to such heroic lengths to fill it suggests
PEP 495 may well be overdue ;-)