[Python-ideas] Date/time literals

Alexander Belopolsky alexander.belopolsky at gmail.com
Tue Jun 1 17:07:51 CEST 2010


On Tue, Jun 1, 2010 at 10:08 AM, Guido van Rossum <guido at python.org> 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.
>

The POSIX standard was heavily influenced by the desire to preserve
last century's existing practices.  Its notable that even the leap
year rule was initially specified incorrectly and only fixed in 2001
version.

Here is the post that I find intriguing:
http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html

An excerpt:

"""
In addition these "glued to the table" cards, there were a number
of unfortunate attitudes:

    "Don't confuse people with UTC.  Everyone uses GMT and knows
    what it means".

    "Lets not complicate things by worrying about the fact that
    the year 2100 is not a leap year."

    "You mean the year 2000 is, but 2100 is not a leap year?"

    "Everyone knows there are only 60 seconds in a minute."

    "I'm lucky if my system's clock is accurate to the minute, so
     I could care less about sometime as small as a leap second".

    "It takes hours, sometime days, for my EMail message to
     reach most people.  Why should I worry about something as
     small as a second?"

    "What matters to me is just that POSIX systems produce the
     same ctime(3) string (i.e., Wed Jun 30 21:49:08 1993\n") when
     given the same time(2) time-stamp."

    "SI?  TAI?  UT1?  I'm having trouble with using UTC instead
     of good old GMT!".
"""

Systems that are aware of leap seconds are not that uncommon.  BSD
derivatives including Mac OS X have time2posix() and posix2time()
functions.  NTP distributes leap seconds notifications.  Any system
that takes time from a GPS source needs to make a leap second
translation.

I think what Mark meant by "easy fixes" was not leap second aware
timestamp to datetime and back translations or datetime arithmetics,
but instead just the ability to store 23:59:60 in time/datetime
object.  This would allow leap second aware applications to use
standard objects to store time and implement arithmetics as correction
to the standard datetime arithmetics.  This is much easier than to
reimplement  the entire datetime module from scratch.



More information about the Python-ideas mailing list