[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
