[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <529FD33A.8000509@skarnet.org>
Date: Thu, 05 Dec 2013 01:13:30 +0000
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
OK, so actually, the patch was right: in a zoneinfo file containing leap
seconds, the transition times are given in TAI-10, not "UTC seconds", i.e.
times with leap seconds *added*.
(Yes, this is confusing, and the tzfile documentation does not make it
clear enough, but it's the only behaviour that makes sense.)
So all the calculations involving times given in seconds, including
transition times, are done within the same referential. i.e. TAI-10,
and this is also valid for __tm_gmtoff.
Only when converting from/to "seconds since the Epoch" to/from "struct tm"
must leap seconds be substracted/added.
The new version of the patch, provided in attachment, reads leap seconds
directly from the mmapped zoneinfo file instead of storing them in a static
table, as requested by Rich; and it's still not invasive.
The leap second table scan is still linear, because:
* when substracting leap seconds, the scan is done from the future to the past.
Since the huge majority of calls involve the current time or a time close to it,
the scan usually stops at the first or second element.
* when adding leap seconds, the scan has to be done from the past to the future
linearly anyway, to apply successive corrections while testing the correct TAI-10
transition time instead of comparing a UTC value to a TAI-10 value. The previous
version of the patch didn't get this right.
I would love it if this version, modulo any bugs, could make it into 0.9.15.
--
Laurent
View attachment "leapsecs.patch" of type "text/plain" (3820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
