[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131205144311.GG24286@brightrain.aerifal.cx>
Date: Thu, 5 Dec 2013 09:43:11 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
On Thu, Dec 05, 2013 at 01:13:30AM +0000, Laurent Bercot wrote:
> 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.
I don't want to disappoint you but I don't think that's feasible.
There's still a lot to be considered about this patch, and it _is_
invasive. The biggest invasive changes are the interface contract
violations for gmtime; after the patch:
- gmtime depends on the TZ variable
- gmtime behaves unpredictably depending on whether a function that
loads the timezone has or has not been called prior to calling
gmtime.
- there's no synchronization in gmtime's (or gmtime_r's) access to the
leap seconds data so the latter isn't even thread-safe.
There may still be other things too I'm not aware of, but the above
are what I noticed immediately.
What I can tell you is that this code (the time internals) is not
something I expect to make any changes to between now and some time
after 1.0, so for your own usage or usage by anybody else who wants
it, your patch should continue to apply successfully. And I don't mind
further discussion of how to improve it in the mean time, but in the
immediate future my focus on musl will be getting 0.9.15 and 1.0.0
releases ready according to the existing plan, without big invasive
changes.
Rich
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.
