On Tue, Jun 1, 2010 at 11:10 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Tue, Jun 1, 2010 at 12:17 PM, Guido van Rossum <guido@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@gmail.com> wrote:
On Tue, Jun 1, 2010 at 1:44 PM, MRAB <python@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)