[Python-ideas] Date/time literals
dickinsm at gmail.com
Tue Jun 1 16:41:10 CEST 2010
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
>>> 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).
More information about the Python-ideas