On Tue, Jun 1, 2010 at 3:08 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Jun 1, 2010 at 2:00 AM, Mark Dickinson <dickinsm@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). Mark