[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...
Guido van Rossum
guido at python.org
Tue Aug 18 19:22:26 CEST 2015
On Tue, Aug 18, 2015 at 8:38 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:
> On Tue, Aug 18, 2015 at 11:07 AM, Guido van Rossum <guido at python.org>
> > PEP 500 allows way more freedom than is needed.
> This is right. With respect to finding elapsed time between two times
> (x and y) expressed as datetime instances, PEP-0500 allow tzinfo
> implementor to provide an arbitrary function of two variables: d(x,
> y), while arguably in most cases d(x, y) = x - f(x) - y + f(y), where
> f is a function of a single variable. (In terms of current tzinfo
> interface, f is the utcoffset() function.) In other words, the PEP
> allows arbitrary stretching and shrinking of the time line, while in
> most use cases only cutting and shifting is needed.
> However, I don't see this additional freedom as a big complication.
> Even in the common case, it may be easier to implement d(x, y) than to
> figure out f(x). The problem with f(x) is that it is the UTC offset
> as a function of local time while most TZ database interfaces only
> provide UTC offset as a function of UTC time. As a result, it is
> often easier to implement d(x, y) (for example, as d(x, y) = g(x) -
> g(y)) than to implement f(x).
This discussion sounds overly abstract. ISTM that d(x, y) in timeline
arithmetic can be computed as x.timestamp() - y.timestamp(), (and
converting to a timedelta). Similar for adding a datetime and a timedelta.
Optimizing this should be IMO the only question is how should a datetime
object choose between classic arithmetic and timeline arithmetic. My
proposal here is to make that a boolean property of the tzinfo object -- we
could either use a marker subclass or an attribute whose absence implies
 Classic arithmetic is how datetime arithmetic works today, i.e. if you
add 24 hours to 12:00 on the Saturday before a DST transition, the answer
will be 12:00 on Sunday (whereas using timeline arithmetic the answer would
be 11:00 or 13:00 depending on which DST transition you're talking about).
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG