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

[ISAAC J SCHWABACHER]

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

[Tim Peters]
> Have fun ;-)

Always! :)

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

PEP 431 did. But I agree, PEP 495 is a small and straightforward step in the right direction. Though it's not looking like the bikeshed is going to get painted my color. :)

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

Wait... was this ever in contention? 

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

I assume pytz is committed for backward compatibility to timeline arithmetic for datetime subtraction, which means it can't afford to change its "one tz instance per offset" design as long as datetime arithmetic ignores the time zone when it's identical. There's no hook for pytz to hang its behavior on, and PEP 495 doesn't give it one. On the upside, it does look like there's a way to foil the dreaded self check in datetime_astimezone and make dt.astimezone(tz) work as intended.

ijs