[Datetime-SIG] Conversion vs arithmetic (was Re: Is EDT a timezone? Was: PEP-0500)

[Tim Peters]

[ijs]
> But here you're talking about the backward compatibility
> problem, not the infinite regress problem.

If a change causes an infinite regress in formerly working code, then
it's a "backward compatibility" problem too.  If you write code from
the start with the change in mind, of course there's no _inherent_
"infinite regress problem".


> I guess I'll have to try to implement it and find out
> where the headaches are myself.

Have fun ;-)

> It's also worth noting that backward compatibility cuts both
> ways: because Stuart Bishop has chosen to implement
> timeline arithmetic, any stdlib inclusion of pytz will have to
> support timeline arithmetic in some form in order to
> maintain backward compatibility with the package itself.

We _could_ include pytz exactly the way it is today, without changing
anything (else) in Python or pytz.  There are lots of ways to deal
with this.  We could also say, more like dateutil did, that Python
finds the Olson database useful but wants _nothing_ to do with
timeline arithmetic, not ever.  Etc.

In any case, there is no active PEP at the moment proposing to add any
new timezone implementations to Python.  One step at a time.


> I see how PEP 495 makes it possible to convert datetimes correctly
> in all cases,

Whew!  You may well be only the second person to grasp this - thanks :-)


> but I don't see how it makes it possible to implement
> time zones that will be pytz-compatible without continuing to require
> the localize/normalize dance.

Indeed it doesn't - nor does it preclude it.  PEP 495 says nothing
whatsoever about timeline arithmetic, or about any other feature of
any external timezone library except to the extent it adds new
requirements on their Python-specifed tzinfo methods (chiefly
.utcoffset() and .fromutc()).

If pytz plays along with 495, then there's a new baseline to start
from.  For example, the current (I think) ptyz docs say:

"""
Converting between timezones also needs special attention. We also need
to use the ``normalize()`` method to ensure the conversion is correct.
"""

That dance "should" no longer be necessary.  But I don't know -
perhaps pytz will continue to need it anyway.  That's up to Stuart,
not to me.