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

[ISAAC J SCHWABACHER]

[ijs]
> > People keep talking about infinite regress, but I don't think
> > there's a problem there at all because in the internals of the
> > time zone conversion, you can strip off the time zone before
> > doing arithmetic. Am I missing something here?

[Tim Peters]
> Yes:  magic doesn't exist in the real world ;-)  All places relying on
> classic arithmetic _could_ be repaired if timeline arithmetic were
> made mandatory, but finding them would require an exhaustive expert
> audit of all instances of aware-datetime arithmetic in all the world's
> code.  It only requires finding one such instance to prove that code
> _would_ break if the default were changed.  I didn't look for one - I
> just happened to notice one in .astimezone().    I have no idea how
> many such places Lennart found across the 2+ years PEP 431 was
> struggling to finish (but I also have no idea about the _details_ of
> the problems Lennart hit).

But here you're talking about the backward compatibility problem, not the infinite regress problem. I guess I'll have to try to implement it and find out where the headaches are myself.

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. I see how PEP 495 makes it possible to convert datetimes correctly in all cases, 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.

ijs