<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 18, 2015 at 8:38 AM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Aug 18, 2015 at 11:07 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> PEP 500 allows way more freedom than is needed.<br>
<br>
</span>This is right.  With respect to finding elapsed time between two times<br>
(x and y) expressed as datetime instances, PEP-0500 allow tzinfo<br>
implementor to provide an arbitrary function of two variables: d(x,<br>
y), while arguably in most cases d(x, y) = x - f(x) - y + f(y), where<br>
f is a function of a single variable.  (In terms of current tzinfo<br>
interface, f is the utcoffset() function.)  In other words, the PEP<br>
allows arbitrary stretching and shrinking of the time line, while in<br>
most use cases only cutting and shifting is needed.<br>
<br>
However, I don't see this additional freedom as a big complication.<br>
Even in the common case, it may be easier to implement d(x, y) than to<br>
figure out f(x).  The problem with f(x) is that it is the UTC offset<br>
as a function of local time while most TZ database interfaces only<br>
provide UTC offset as a function of UTC time.  As a result, it is<br>
often easier to implement d(x, y) (for example, as d(x, y) = g(x) -<br>
g(y)) than to implement f(x).<br>
</blockquote></div><br></div><div class="gmail_extra">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[1] 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.<br><br></div><div class="gmail_extra">[1] 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).<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>