[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