[Python-ideas] Date/time literals

[Guido van Rossum]

On Tue, Jun 1, 2010 at 8:07 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> 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.

I don't expect this century's practices will change much. Show me a a
labor contract with a provision to pay for work during leap seconds
and I might change my mind.

> Its notable that even the leap
> year rule was initially specified incorrectly and only fixed in 2001
> version.

I don't see how that's an argument for supporting leap seconds. The
change here is really about the expectation of the lifetime of
software systems, not unlike what caused Y2K.

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

A rants by someone with a grudge.

> 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!".
> """

He throws ripe and green comments together in a way to make it sound
as if not knowing the Gregorian leap year rule is of the same
magnitude as not caring about leap seconds or TAI.

> 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.

That's a solved problem though, is it? The accounting for leap seconds
properly belongs in the layers closest to NTP / GPS.

All other software running in the typical computer (even Google's
servers) uses interfaces that use POSIX timestamps (albeit often with
fractions of a second supportd) or something logically equivalent.

> 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.

Tell us about the use case.

Note that if you're talking about times in the future (a very useful
use case for the datetime module) you *can't* account for leap seconds
since it is not known (far) ahead when they will be.

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