[Datetime-SIG] PEP-431/495

Akira Li 4kir4.1i at gmail.com
Tue Aug 25 08:39:27 CEST 2015


Stuart Bishop <stuart at stuartbishop.net> writes:

> On 25 August 2015 at 01:02, Guido van Rossum <guido at python.org> wrote:
>
>> I'm still confused about what makes Stuart believe a tzinfo database must
>> also change the arithmetic rules (especially since Gustavo's dateutils
>> apparently gets along quite well without this).
>
> A tzinfo database does not care about the arithmetic rules.
>
> The database provided by pytz is designed in such a way that you get
> correct timeline arithmetic out of Python's datetime library, by
> exposing each period in the timezone definition as distinct fixed
> offset tzinfo instances.
>
>>>> from datetime import datetime, timezone, timedelta
>>>> from pytz.reference import Eastern as reftz  # Tim's reference implementation
>>>> import pytz
>>>> dt = datetime(2004, 4, 4, 6, 59, tzinfo=timezone.utc)
>>>> str(dt.astimezone(pytz.timezone('US/Eastern')))
> '2004-04-04 01:59:00-05:00'
>>>> str(dt.astimezone(reftz))
> '2004-04-04 01:59:00-05:00'
>>>> str(dt.astimezone(pytz.timezone('US/Eastern')) + timedelta(minutes=1))
> '2004-04-04 02:00:00-05:00'
>>>> str(dt.astimezone(reftz) + timedelta(minutes=1))
> '2004-04-04 02:00:00-04:00'
>
> So I think pytz's current implementation is entwined with the
> arithmetic style. But the tzfile loader in pytz could be reworked to
> present tzinfo instances suitable for classic arithmetic if you want
> it in stdlib, or the parser out of dateutils used.

As far as I know utc -> local timezone *conversions* do not work during
DST transitions in dateutil [1] while pytz manages just fine.

Let's not do, whatever dateutil does here. It would be a regression.

The result does not depend on the datetime implementation details. Given
a specific tz db version the utc -> local conversion is not a matter of
interpretation for recent dates.

pytz is the only Python library that does timezone *conversions*
correctly for almost all timezones from the tz database in a +/- decade
time range.

If pep-495 does not help pytz with timezone conversions then what is the
point of pep-495?


[1] https://github.com/dateutil/dateutil/issues/112



More information about the Datetime-SIG mailing list