[Datetime-SIG] What's are the issues?

Tim Peters tim.peters at gmail.com
Wed Jul 29 03:09:23 CEST 2015


[Felipe Ochoa <felipe.nospam.ochoa at gmail.com>]
> ...
> I'm less clear on the issue here, but Isaac seemed to disagree with the
> algorithm in datetime.py
> (https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1935)
> [http://code.activestate.com/lists/python-dev/137300/]

The algorithm is fine, so far as it goes (with which Isaac will agree).

"So how far does it go?" ;-)  It handles DST transitions correctly in
all known timezones(*).

But, as the docs have always pointed out, it (specifically .fromutc(),
which is at the base of all relevant calculations) doesn't even try to
handle transitions due to _other_ causes.  The only other such cause
I'm aware of is when a timezone's _base_ offset from UTC changes (not
a temporary DST transition, the timezone's "standard" offset changes
permanently (meaning until someone decides to change it again)).

Many timezones have suffered such a fundamental redefinition at least
once.  There is no pattern whatsoever to when such things occur -
seems it's driven purely by local politics.  And for any given
timezone it typically happens at most once across its lifetime to
date.  However, while rare, such changes do still happen, and a
"wholly correct" implementation needs to cater to them too (meaning a
more general .fromutc() implementation needs to be crafted, and the
docs updated to match the new scheme).

>From there, Isaac went on to define an approach to a more general
method, which could obviously handle that kind of thing too.  How
practical that approach can be made remains unknown, because nobody
yet (that I know of) has tried to produce corresponding code.  The
mathematical abstractions in his writeup appear far more general than
actually needed for any timezone yet invented (excepting the absurd
"RIyadh Solar" timezone experiment, which was never actually used by
anyone in the real world); stronger assumptions could probably allow
more efficient implementation.


(*) By "timezone" I mean whatever rules a specific tzinfo instance
implements.  I have a wholly Python-centric view of everything ;-)


More information about the Datetime-SIG mailing list