[Datetime-SIG] Timeline arithmetic?

[Tim Peters]

[Chris Barker <chris.barker at noaa.gov>]
> It seems to me that it's clear that timeline arithmetic will not get
> implemented in concert with PEP 495.

It's certainly not _part_ of 495.  495 aims to fix timezone
conversions in all cases for code that's already working fine in all
other respects.  Tying that to timeline arithmetic would wholly miss
the "for code that's already working fine" goal.  Carl's scheme would
tie fixing conversions _to_ using a brand new builtin implementation
of timeline arithmetic, so would do nothing for existing code (would
neither hurt nor help it, although all code currently doing arithmetic
on aware datetimes could fail in subtle or gross ways _if_ it tried
using one of Carl's new tzinfos).


> So -- is the door open to a PEP that DOES implement timeline
> arithmetic with tz-aware datetimes in the standard lib?

I would say instead the door isn't shut ;-)  Note that Guido already
rejected PEP 500, which proposed one way to allow it.  He didn't like
its generality.  A PEP concerned with timeline arithmetic alone would
overcome that objection.

But you have to know by now that datetime always intended that apps
needing timeline arithmetic use UTC instead (or timestamps), and
there's scarcely an experienced voice on the planet that would
_recommend_ doing it any other way.  Building in "by magic" timeline
arithmetic would be fighting both datetime's design and universally
recognized best practice.  So I dare to say it will never be
_attractive_ to Guido.  At best it could get grudging acceptance.

Which is possible!  Just want to make clear that it's likely to be an
uphill fight.

Note that PEP 495 may also be rejected.  "Grudging acceptance" is the
best 495 can do too (always-correct conversions are an interest of
mine, not particularly of Guido's - but, to be fair, at least Guido
doesn't hate the idea of fixing conversions ;-) ).


> ...
> Also, particularly as PEP 495 will introduce changes to tzinfo, that will
> presumable lead to changes in tzinfo implementations (like pytz, etc), it
> seems that if other changes are afoot, now is a good time to map out how
> they should be done.

It seems 495 really doesn't do anything for pytz, so I'm not sure
Stuart would bother to implement 495-conforming tzinfos.  _Someone_
will, though.  Eventually ;-)


> Stuart, if you are listening:
>
> IIUC, you want "timeline" arithmetic to work with pytz tzinfo-aware
> datetimes. To the extent that the current implementation functions in a
> maybe "hacky", and at least inconvenient, way to achieve this.
>
> So you are an obvious person to say what we might put in the stdlib that
> would facilitate cleaning all that up. If anything.
>
> BTW: I'll at least take it as a given that we're not breaking backward
> compatibility, and that arithmetic needs to stay as fast as it currently is
> -- at least in the cases where it currently works.

A timeline arithmetic PEP would have to ensure that timeline
arithmetic is never used unless a programmer explicitly asks for it.
PEP 500 met that goal, and so does Carl's scheme (both via the same
basic mechanism:  by the user asking for a new flavor of tzinfo).