On Tue, Jun 1, 2010 at 8:23 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Tue, Jun 1, 2010 at 10:41 AM, Mark Dickinson <dickinsm@gmail.com> wrote: ..
As per the POSIX standard (IIUC), [datetime(1985, 6, 30, 23, 59, 60)] would be immediately converted to datetime.datetime(1985, 7, 1, 0, 0, 0) internally. So the datetime object itself wouldn't support leap seconds, and would continue to use POSIX time; only the constructor would support leap seconds.
It is my understanding that POSIX mandates that mktime() function normalizes the tm structure and therefore converts (1985, 6, 30, 23, 59, 60, ...) to (1985, 7, 1, 0, 0, 0, ...). It is not quite accurate to say that tm structure is converted "immediately". It is perfectly legal to pass around non-normalized tm structures and have for example utc2gps() function that would produce different values for Y-M-D 23:59:60 and T-M-[D+1] 00:00:00.
I would prefer a similar behavior for datetime constructor:
datetime(1985, 6, 30, 23, 59, 60).second 60 datetime(1985, 6, 30, 23, 59, 60).timetuple() (1985, 6, 30, 23, 59, 60, ...)
but
datetime(1985, 6, 30, 23, 59, 60) - datetime(1985, 7, 1, 0, 0, 0) datetime.timedelta(0)
I expect this will cause a lot of subtle issues. E.g. What should comparison of an unnormalized datetime value to an equivalent normalized datetime value yield? 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) ? How do you force normalization? Won't it break apps if the .seconds attribute can be out of range or if normalization calls need to be inserted? The datetime module was written with "commercial" and everyday use in mind. In such use, there is no need to carry leap seconds around. -- --Guido van Rossum (python.org/~guido)