Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Dec 2013 06:31:46 +0100
From: Szabolcs Nagy <>
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files

* Laurent Bercot <> [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.