Are there any "correct" implementations of tzinfo?

[Carl Meyer]

On 09/12/2015 12:23 PM, Random832 wrote:
> 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. 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?

Well, the problem is that because datetime doesn't include any way to
disambiguate ambiguous times, it's not really possible to implement
complex timezones in a way that is both correct (if your definition of
correct includes "timezone conversions are lossless") and also matches
the intended model of datetime.

I believe that dateutil.tz has a tzinfo implementation (though I haven't
used it myself) which is zoneinfo-based and matches the intended model
of datetime (in that "Eastern" is always the same tzinfo object, and all
operations within "Eastern" are always done on a local-clock-time
basis). But in order to do this it has to sacrifice round-trippable
conversions during a DST fold (because it has no way to disambiguate
between the first and second 1:30am in local time during a DST fold).

Pytz makes the other choice, making all operations consistent and
loss-less by using only fixed-offset tzinfo instances. The cost of this
choice is the need to "normalize" after arithmetic, because you may end
up with e.g. an EDT datetime during a timeframe when DST is not in
effect and it should be EST instead.

PEP 495 is intended to solve the "no way to disambiguate ambiguous local
times other than using fixed-offset tzinfos" problem, which would make
it possible to implement tzinfo classes following the dateutil model
while still having loss-less conversions.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20150912/e6c57c21/attachment.sig>