[Datetime-SIG] Fwd: Calendar vs timespan calculations...

Alexander Belopolsky alexander.belopolsky at gmail.com
Tue Aug 4 18:29:24 CEST 2015

On Tue, Aug 4, 2015 at 12:13 PM, Chris Barker <chris.barker at noaa.gov> wrote:
>> On Aug 3, 2015, at 9:11 PM, Tim Peters <tim.peters at gmail.com> wrote:
>> Sorry about this.  I don't want to talk about leap seconds anymore,
> Nor do I, but
> TL;DR -- leap seconds are in the definition of UTC.

I have not reflected this in the PEP, but in the reference
implementation, I am toying with the following bit of "leap seconds

diff --git a/Lib/datetime.py b/Lib/datetime.py
-        ss = min(ss, 59)    # clamp out leap seconds if the platform has them
-        return cls(y, m, d, hh, mm, ss, us)
+        ss, first = (ss, True) if ss < 60 else (59, False)
+        return cls(y, m, d, hh, mm, ss, us, first=first)

See <https://github.com/abalkin/cpython/commit/a54ab4502b9b50ae87d7795930fd13e70dbb17fa>.

Note that even though many people claim that POSIX does not support
leap seconds, this
is only true with respect to the time_t timestamps and does not apply
to the broken down
tm structure which is more directly related to Python datetime than
"seconds since EPOCH."

To the contrary, leap seconds support is mandated by POSIX in the case
of struct tm:

The <time.h> header shall declare the structure tm, which shall
include at least the following members:

int    tm_sec   Seconds [0,60].

The range [0,60] for tm_sec allows for the occasional leap second.

See <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html>.

More information about the Datetime-SIG mailing list