On Tue, Aug 18, 2015 at 8:38 AM, Alexander Belopolsky < [email protected]> wrote:
> On Tue, Aug 18, 2015 at 11:07 AM, Guido van Rossum <[email protected]> > wrote: > > 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[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. [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). -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
