[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