[Python-Dev] Status on PEP-431 Timezones

[Alexander Belopolsky]

On Wed, Apr 15, 2015 at 5:28 PM, Stuart Bishop <stuart at stuartbishop.net>
wrote:
>
> On 15 April 2015 at 21:51, Lennart Regebro <regebro at gmail.com> wrote:
> > On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop <stuart at stuartbishop.net>
wrote:
>
> > Just punting it to tzinfo to make adjustments, ie effectively just
> > doing what normalize() does creates infinite recursion as there is
> > more arithmetic in there, so it's not quite that simple.
>
> This sounds familiar. Its infinite recursion if the tzinfo does its
> calculations using localized datetimes. If the tzinfo is stripped for
> the calculations, there is no tzinfo to recurse into. At least this
> was how I hoped it would work, and it sucks if it doesn't. You could
> be right that using the UTC representation internally for datetimes
> with a tzinfo makes the most sense.

There is no infinite recursion in the way datetime module deals with zone
conversions.   However, implementors of tzinfo subclasses often overlook
the fact that datetime module design mandates specific rules for what
utcoffset() should return for the missing and ambiguous hours. Granted, the
relevant section in the manual [1] is not an easy read and in fact for a
long time that documentation itself was displaying a buggy implementation
of the LocalTimezone class. [2]

Understanding how the design works requires a bit of algebra [3], but I
strongly recommend that anyone trying to improve the timezones support in
the datetime module, print out those 200 lines of comments and go through
them with a pencil following the proofs.

Note that one of the key assumptions [3.2] in that write-up does not hold
in real life.  The assumption is that "standard time" offset does not
depend on the point in time.  However, I do believe that this assumption
can be relaxed without invalidating the main result.   I believe we can
still have unambiguous fromutc() as long as standard time offset does not
change "too often."  Basically, if we (generously)  allow utcoffset to vary
from -24h to +24h, then a "sane" zone can be defined as the one where
utcoffset changes at most once in any 48 hour period.

If I am right about this and the algebra works out, then we don't need to
change datetime module design to properly support all world timezones.

[1] https://docs.python.org/3/library/datetime.html#datetime.tzinfo.fromutc
[2] http://bugs.python.org/issue9063
[3] https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1935
[3.2] https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1948
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150415/a35529a7/attachment-0001.html>