[Datetime-SIG] PEP-431/495

Guido van Rossum guido at python.org
Mon Aug 24 20:02:49 CEST 2015

On Mon, Aug 24, 2015 at 10:44 AM, Carl Meyer <carl at oddbird.net> wrote:

> On 08/24/2015 11:18 AM, Guido van Rossum wrote:
> > I'm still unclear on why pytz solves two problems (timeline arithmetic
> > and a tzinfo database). What is the linkage between the two besides that
> > you (Stuart) feels that both are important problems to solve?
> Didn't Stuart already answer this in his last email?
> "Grump. I always interpreted that documentation to mean that timezone
> conversions where *my* problem as the author of the tzinfo
> implementation. I thought it was a documented problem to be fixed
> if/when Python ever provided more complex tzinfo implementations, and
> one of the reasons it never did provide such implementations in the
> first place."

I guess he assumed wrong. We didn't consider the arithmetic we implemented
broken at all. Our assumptions at the time were:

- If you want timeline arithmetic you will obviously be using UTC (either
POSIX timestamps or datetime instances with assumed or explicit UTC)

- Implementing a tzinfo database is a huge project that we'd like to tackle
at some point in the future (possibly as a 3rd party project)

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).

> "Classic behaviour as you describe it is a bug. It sounds ok when you
> state it as 'add one day to today and you get the same time tomorrow'.
> It does not sound ok when you state it as 'add one second to now and
> you will normally get now + 1 second, but sometimes you will get an
> instant further in the future, and sometimes you will get an instant
> in the past'."

That sounds tautological to me -- "it's a bug because I find it buggy".

Maybe the underlying reason is that to me, even a datetime with tzinfo does
not refer to an instant -- it refers to something that's displayed on a
clock. To me, arithmetic is a way of moving the hands of the clock.

In other words, he just assumed that timeline arithmetic was his only
> reasonable option as the author of a useful, non-buggy tzinfo
> implementation. As a user of pytz, it was certainly what I expected, and
> I'd have considered "classic arithmetic" to be a bug (thanks to pytz, I
> avoided even knowing that was Python's default behavior until this
> thread), so I can't fault his assumption.

But again that proves nothing. Of course if you're used to pytz's behavior
you'll find the other behavior buggy. And it still does nothing to explain
(to me) why the two need to be inextricably linked.

> I think the other linkage between the two is that pytz's "every tzinfo
> instance is fixed-offset" is the most natural way to solve the PEP-495
> problem in the absence of PEP 495 and ensure that all datetime instances
> are unambiguous and valid.

Again (as can be seen from the endless bickering between Alexander and
myself about whether this is a bug or not) your view is colored by pytz's

> Faced with "I need to store this extra
> disambiguation bit in the tzinfo somehow, to clarify which of two
> offsets is intended when a timezone transitions from one offset to
> another", you can either store a boolean somewhere which is usually
> irrelevant and very hard to name sensibly, or you can "store" the flag
> by simply assigning a tzinfo instance which represents the specific
> offset you want (but also knows its full timezone rules, so it can
> "normalize" to a different offset when asked to).

But almost all instants (99.98%, according to Alexander) are not ambiguous
and have no need for the disambiguation. If I every program an alarm to
occur weekday at 7am I'd be most disturbed if an implementation botched the
DST transition and woke me up at 6am one Monday morning. And yet that 7am
is in a specific timezone (mine!).

> Once you choose the latter implementation (which you might reasonably
> choose even if you didn't care about arithmetic at all), Python gives
> you timeline arithmetic automatically.

You've proved nothing except that pytz's view is seductive. :-)

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150824/2b47a351/attachment-0001.html>

More information about the Datetime-SIG mailing list