[Datetime-SIG] Timeline arithmetic?

[Alexander Belopolsky]

On Fri, Sep 4, 2015 at 2:38 PM, Chris Barker <chris.barker at noaa.gov> wrote:

> On Fri, Sep 4, 2015 at 11:19 AM, Carl Meyer <carl at oddbird.net> wrote:
>
>> On 09/04/2015 12:11 PM, Alexander Belopolsky wrote:
>> > Keep in mind that the standard library should not only support "casual
>> > users", but also those who will write a "period
>> > recurrence library" for those "casual users."  This is where classic
>> > arithmetic is indispensable.
>>
>
> I dont get that at all -- a Period recurrence lib needs to know all sorts
> of stuff about the timezone, and other things, like days of the week. And
> it needs to be able to do "timeline arithmetic", but it would presumable be
> able to remove and tack back on a tzinfo object all on it's own  -- i.e. so
> the arithmetic it wants.
>

Let me try again.  In my view, datetime class is a fancy way to encode
315537897600000000 integers:

>>> 1 + (datetime.max - datetime.min) // datetime.resolution
315537897600000000

A timedelta class is a slightly less fancy way to encode some
other 172799999913600000000 integers.  The *natural* arithmetic on datetime
and timedelta objects stems from the bijection between them and long
integers.

>>> t = datetime.now()
>>> i = (t - datetime.min) // datetime.resolution
>>> t == datetime.min + i * datetime.resolution
True

>>> d = timedelta(0, random())
>>> j = (d - timedelta.min) // timedelta.resolution
>>> d == timedelta.min + j * timedelta.resolution
True

The "arithmetic" that datetime module implements is an efficient way to do
addition and subtraction of datetime/timedelta objects without an explicit
round trip to long integers (even though at the implementation level a
round trip may take place).

This arithmetic forms the basis for anything that you may want to do with
datetimes: compute the number of business days in a year, compute the
number of seconds in a century with or without the leap seconds, compute
the angle in radians between the long hand and short hand of the Big Ben at
17:45:33.01 New York time.

Timeline arithmetic is one of the simpler applications of the *natural*
arithmetic provided by the datetime module: the timeline difference between
t1 and t2 (assuming t1.tzinfo is t2.tzinfo) is just (t1 - t1.utcoffset()) -
(t2 -  t2.utcoffset()).  Since "naive" difference between t1 and t2 that
don't share tzinfo does not make sense, it was defined as a timeline
difference.  I think that was a mistake.  I believe both Tim and Guido
expressed a similar sentiment at various times.  If datetime was designed
today, t1 - t2 where t1.tzinfo is not t2.tzinfo would be an error and the
user would have to choose between t1 - t2.astimezone(t1.tzinfo),
t1.astimezone(t2.tzinfo) - t2 or t1.astimezone(utc) - t2.astimezone(utc)
depending on the application need and with a full understanding that these
three expressions can produce different results.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150904/8a10093b/attachment.html>