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)