[Python-ideas] Date/time literals

[Guido van Rossum]

On Tue, Jun 1, 2010 at 7:41 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Tue, Jun 1, 2010 at 3:08 PM, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Jun 1, 2010 at 2:00 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
>>> Some of the issues you mention look like easy fixes (e.g., allowing
>>> positive leap seconds, allowing '24:00:00' as a valid time).
>>
>> Whoa, the datetime module was explicitly designed not to support leap
>> seconds. This matches the POSIX standard for timestamps, which,
>> although commonly explained as "seconds since 1/1/1970 UTC" doesn't
>> count leap seconds either (it would make the conversions between
>> timestamps and date/time objects horribly complicated since leap
>> seconds are not determined by an algorithm). This is all intentional,
>> since leap seconds are designed to be ignorable by most people except
>> a few communities like astronomers, who have their own clocks.
>
> Yes, I understand these issues: UTC is not POSIX time.  By 'support
> for leap seconds', all I meant (and all I was assuming Masklinn meant)
> was that it would be helpful for e.g., datetime.datetime(1985, 6, 30,
> 23, 59, 60) to be accepted, rather producing a ValueError as it
> currently does:
>
>>>> datetime.datetime(1985, 6, 30, 23, 59, 60)
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> ValueError: second must be in 0..59
>
> As per the POSIX standard (IIUC), that 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.
>
> Similar comments apply to accepting a time of 24:00:00 (and converting
> it internally to 00:00:00 on the following day).

What's the use case for these relaxations in argument range checking?
I'd say they are more confusing, since they might lead one to suspect
that leap seconds are in fact supported.

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