[Dachs-support] question about leap seconds

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue Feb 8 11:33:35 CET 2022


Hi again,

For the archive:

On Mon, Feb 07, 2022 at 04:51:33PM +0100, Markus Demleitner wrote:
> > As a matter of fact, this ISO date is correct, since there was a
> > leap second inserted at this time. This means that the last second
> > of year 2016 is indeed '2016-12-31T23:59:60.000'. 
> 
> Well, there's always a bit of trouble I've not forseen.  What DaCHS
> does here is dissect the iso datestring a bit more robustly than the
> normal time parser does and then passes the bits on to
> datetime.datetime.

Well, I've now added a mode that goes through calendar.timegm and
thus deals with leap seconds; just pass useTime=true:

	>>> parseISODT("2016-12-31T23:59:60")
	Traceback (most recent call last):
	ValueError: second must be in 0..59
	>>> parseISODT("2016-12-31T23:59:60", useTime=True)
	datetime.datetime(2017, 1, 1, 1, 0)

This will be in starting version 2.6 or beta 2.5.3.  Baptiste, if
you'd like to have this now, I could make that beta on short notice;
if you don't shout I'll assume you use the apply I sent around
yesterday (including misplaced parenthesis) and wait with the beta.

In case you're wondering why I'm not always using the leap
second-aware code: I suspect that on many platforms,
datetime.datetime still covers a much larger time span than unix
timestamps (not sure who has adopted 64 bit timestamps already; it's
still a few years until 2038).

       -- Markus


More information about the Dachs-support mailing list