[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