[Python-ideas] Date/time literals

[Guido van Rossum]

On Tue, Jun 1, 2010 at 11:10 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Jun 1, 2010 at 12:17 PM, Guido van Rossum <guido at python.org> wrote:
> ..
>> I expect this will cause a lot of subtle issues.
>
> I will try to answer to those.
>
>> E.g. What should
>> comparison of an unnormalized datetime value to an equivalent
>> normalized datetime value yield?
>
> I am not proposing supporting arbitrary unnormalized datetime values,
> only to allow seconds (0 - 60).  I am not proposing any notion of
> "equivalent datetime" objects either.  POSIX will require that for  t1
> = datetime(1985, 6, 30, 23, 59, 60) and t2 =datetime(1985, 7, 1, 0, 0,
> 0) time.mktime(t1.timetuple()) == time.mktime(t2.timetuple()), but
> this does not mean that t1 and t2 should compare equal.
>
> It is a more subtle issue, what difference t1 - t2 should produce.  I
> think it can be defined as difference in corresponding POSIX times.

But consistency within the API is out the window. Currently datetimes
are linearly ordered like numbers and if a difference is zero the two
values are the same.

I think it would be safer for your use case to either store the tuple
or the string representation, if you really need to represent a leap
second.

Also note that there will be no validation possible for future
datetimes (and for past dates it would require an up-to-date leap
second database).

>> How far will you go? Is
>> datetime.datetime(2010, 6, 1, 36, 0, 0) a way of spelling
>> datetime.datetime(2010, 6, 2, 12, 0 0) ?
>
> I would not go any further than extending seconds to 0-60 range which
> is common to many modern standards.

That's good.

>> How do you force
>> normalization?
>
> Normalization is never forced.  A round trip through POSIX timestamp
> will naturally produce normalized datetime objects.

Well code that for whatever reason wants normalized timestamps only
will have to know about this method to force normalization, so it
would be a backwards incompatibility (since currently one can assume
that *all* datetime objects are normalized).

>> Won't it break apps if the .seconds attribute can be
>> out of range or if normalization calls need to be inserted?
>
> Many standards require that seconds range be 0-60.  Applications that
> obtain time from timetuples should already be prepared to handle this
> range to be POSIX compliant.   Note that I do not propose changing
> internal sources of datetime objects such as datetime.now() to return
> dt.seconds == 60.Therefore all extended range times will originate
> outside of the datetime library.  Current application should already
> validate such sources before passing them to datetime library.  Of
> course an application that relies on constructor throwing an exception
> for validation and then asserts that seconds < 60 will break, but this
> can be addressed by proper deprecation schedule.  Maybe even starting
> with enabling  extended seconds range with a from __future__ import.

I see nothing but trouble down this road.

Also: http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds

[and later]
On Tue, Jun 1, 2010 at 11:36 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Jun 1, 2010 at 1:44 PM, MRAB <python at mrabarnett.plus.com> wrote:
> ..
>>> but
>>>>>>
>>>>>> datetime(1985, 6, 30, 23, 59, 60) - datetime(1985, 7, 1, 0, 0, 0)
>>>
>>> datetime.timedelta(0)
>>>
>> Actually, that's wrong because there was a leap second. The clock went:
>>
>>    1985-06-30 23:59:59
>>    1985-06-30 23:59:60
>>    1985-07-01 00:00:00
>>
>> The following year, however, it went:
>>
>>    1986-06-30 23:59:59
>>    1986-07-01 00:00:00
>
> It is only wrong if you expect datetime difference to reflect the
> actual duration between the corresponding UTC events.

What on earth do you mean by *actual duration*? Most datetimes are
derived from clocks that aren't accurate to a second even.

> The datetime
> library does not do it even for dates.
>
> For example, on my system
>
>>>> date(1752, 9, 14) - date(1752, 9, 2)
> datetime.timedelta(12)
>
> even though calendar application on the same machine shows that
> September 14 was the day after September 2 in 1752.

And here you are mixing topics completely -- calendar reform is a
completely different topic from leap seconds.

> $ cal 9 1752
>   September 1752
> Su Mo Tu We Th Fr Sa
>       1  2 14 15 16
> 17 18 19 20 21 22 23
> 24 25 26 27 28 29 30
>
> This was a deliberate design choice to implement proleptic calendar
> rather than a historically more accurate variant.  Similarly I see
> nothing wrong with datetime difference not capturing leap seconds.  An
> application interested in leap seconds effects, however should still
> be able to use the basic datetime object and define its own duration
> functions.

You haven't proven this need at all, and your reference to calendar
reform (which by the way didn't happen in the same year or even
century everywhere) makes it weaker still.

I've put my foot down against leap seconds once before (when datetime
was introduced) and I will do it again.

-- 
--Guido van Rossum (python.org/~guido)