[Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters <tim.peters at gmail.com> wrote:
> However, the _body_ of the PEP said nothing whatsoever about altering
> arithmetic.  The body of the PEP sounds like it's mainly just
> proposing to fold the pytz package into the core.  Perhaps doing
> _just_ that much would get this project unstuck?  Hope springs eternal
> :-)

The pytz package has an API and a usage that is different from the
datetime() module. One of the things you need to do is that after each
time you do arithmetic, you have to normalize the result. This is done
because the original API design did not realize the difficulties and
complexities of timezone handling and therefore left out things like
ambiguous times.

The PEP attemps to improved the datetime modules API so that it can
handle the ambiguous times. It also says that the implementation will
be based on pytz, because it was my assumption that this would be
easy, since pytz already handles ambiguous times. During my attempt of
implementing it I realized it wasn't easy at all, and it wasn't as
easy as folding pytz into the core.

Yes, the PEP gives that impression, because that was the assumption
when I wrote the draft. Just folding pytz into the core without
modifying the API defeats the whole purpose of the PEP, since
installing pytz is a trivial task.

> Like what?  I'm still looking for a concrete example of what "the
> problem" is (or even "a" problem).

A problem is that you have a datetime, and add a timedelata to it, and
it should then result in a datetime that is actually that timedelta
later. And if you subtract the same timedelta from the result, it
should return a datetime that is equal to the original datetime.

This sounds ridiculously simple, and is ridiculously difficult to make
happen in all cases that we want to support (Riyahd time zone and leap
seconds not included). That IS the specific, concrete problem, and if
you don't believe me, there is nothing I can do to convince you.
Perhaps I am a complete moron and simply incompetent to do this, and
in that case I'm sure you could implement this over a day, and then
please do so, but for the love of the founders of computing I'm not
going to spend more time repeating it on this mailing list, because
then we would do better in having you implement this instead of
reading emails. Me repeating this a waste of time for everyone
involved, and I will now stop.

> <discussing why Python's datetime is dfferent>

I was not involved in the discussion then, and even if I had been,
that's still before I knew anything about the topic. I don't know what
the arguments were, and I don't think it's constructive to try to
figure out exactly why that decision was made. That is all to similar
to assigning blame, which only makes people feel bad. Those who get
blamed feel bad, and those who blame feel like dicks and onlookers get
annoyed. Let us look forward instead.

I am operating both without any need to defend that decision, as I was
not involved in it, and I am operating with 20/20 hindsight as I am
one of the few people having tried to implement a timezone
implementation that supports ambiguous datetimes based on that
decision. And then it is perfectly clear and obvious that the decision
was a mistake and that we should rectify it.

The only question for me is how and when.