[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...

[Tim Peters]

[Ethan Furman]
>> Having briefly read PEP 500 it seems to me the primary use case is the DST
>> transition; I can easily imagine experiments, studies, laboratory processes,
>> etc., that need to be aware of how many hours have/will have passed, and
>> being off by that one hour (or 30 minutes, or whatever) is simply not
>> acceptable.

[Guido]
> Yes, but there are other options. PEP 500 allows way more freedom than is
> needed.

Another approach to consider:  _nothing_ is needed beyond PEP 495.  As
PEP 500 shows with concrete code, those who want DST-aware arithmetic
can easily get it (after PEP 495-compliant timezone wrappers are
available - otherwise this approach fails in a handful of cases) via
simple functions.  For example (copy/paste/edit from the PEP):

def timeline_add(dt, delta):
    asutc = dt.astimezone(timezone.utc)
    return (asutc+ delta).astimezone(dt.tzinfo)

That's akin to what I've done in the very few cases I wanted timeline
arithmetic.  It's fine by me that "+" isn't overloaded because I need
so little of this.  Indeed, it's _because_ I need so little of this
that I _prefer_ to use a named function:  that makes it dead obvious
I'm doing something unusual (for me).

Someone could easily convince me _they_ need "a lot" of it.  But
someone else could easily convince me they need "a lot" of
leap-second-aware arithmetic.  It's not for me to say one is right and
the other is wrong.  That's for Guido to say ;-)