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.