Date: Fri, 6 Dec 2013 06:31:46 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files * Laurent Bercot <ska-dietlibc@...rnet.org> [2013-12-06 01:15:52 +0000]: > >At the very least they would have some overhead determining that > >leapseconds aren't in use. > > Indeed, one test at executable start. :) > Do you have any idea what form this test would take, if we're opting > away from TZ ? - musl should not have configuration options that change the behaviour of an api (otherwise maintaining the code becomes much harder) so making leapseconds a libc build time config option does not work - hardcoding leapsecond tables into libc does not work either requires recompilations and restarts - if the clock source is a kernel level setting then the information should come from the kernel (eg in the aux vector or /proc) - if the clock source setting is an external setting (eg the configured time server uses GPS or TAI time scale) then the admin should provide the information through the filesystem, but an update is still an operational hazard, and we need to invent a file format and provide tools to get it from the distributed tzdata files - during the life-time of a process adding leapseconds may cause problems so the data should be cached at startup or on demand at the first gmtime call, but then there might be problems across processes if they don't have the same cached leapsecond list (the 86401 second day can cause problems no matter how we do this: communicating unix time across systems with different time scale or inserting future dates into databases based on unix time when the leap seconds are not yet known, etc)
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.