[Dachs-support] question about leap seconds

Baptiste Cecconi baptiste.cecconi at obspm.fr
Tue Feb 8 11:38:23 CET 2022


Thanks Markus, 
at the moment, I have included a hack in my custom grammar to deal with the issue. 
I'll use your option when the new beta version is out.

Baptiste

> Le 8 févr. 2022 à 11:33, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> a écrit :
> 
> 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
> -- 
> Dachs-support mailing list
> Dachs-support at g-vo.org
> https://lists.g-vo.org/mailman/listinfo/dachs-support



More information about the Dachs-support mailing list