I'm not sure I've completely followed all the ramifications here. Why should one have to restart processes on 1,000s of nodes for something like this? 5 9s contracts are hard enough to satisfy at the best of times, without adding another 30 - 120 seconds of restart impact, degraded performance and failover for large jobs. In the sorts of sites we operate in, there might be just one admin for the entire estate, and they're busy enough, and probably laden down with more special knowledge than they can recall as it is, to have to deal with something like this as well...

From this point of view, a system update of packages and data files should be accommodated automatically. Isn't that what a file watch is for? Actually, I'd argue the same for any change to any file of configuration data used by a library. There's no way an userspace app is going to know with certainty what files its underlying linked libs are using or how.

That said, I'm all for getting this right - but I'll leave it to others what that means, with one caveat. Date and time match has been got wrong in every system (eg a swap pricing engine, a national telco ordering system) and programming language I've used where it actually mattered... Java are on their third cut at it, for starters... Personally, I think apps should just use a monotonic source of seconds from an epoch, and use a well-developed third party lib dedicated to the problem if they need date math (eg Joda time in Java).


On 6 December 2013 10:48, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:

- 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

 Also, that would break musl's policy of "compile once, run
everywhere". Leap second usage should be a system-wide setting,
not a binary-wide setting.



- hardcoding leapsecond tables into libc does not work either
   requires recompilations and restarts

 Of course. Leap second tables should be read either from the
timezone files, as glibc does, or from a separate file.



- 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,

 musl shouldn't try to autodetect settings from the kernel. The
admin should be the authoritative source of information.



   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

 That's the easy part. I'm already doing that for skalibs. I'm
willing to provide the format and the tools.



- 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

 Again, leap second announcements are a rare event and there's
plenty of time for admins to restart their processes. I don't
think that's something musl should care about.

--
 Laurent