Also, that would break musl's policy of "compile once, run
- 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
everywhere". Leap second usage should be a system-wide setting,
not a binary-wide setting.Of course. Leap second tables should be read either from the
- hardcoding leapsecond tables into libc does not work either
requires recompilations and restarts
timezone files, as glibc does, or from a separate file.musl shouldn't try to autodetect settings from the kernel. The
- 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,
admin should be the authoritative source of information.That's the easy part. I'm already doing that for skalibs. I'm
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
willing to provide the format and the tools.Again, leap second announcements are a rare event and there's
- 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
plenty of time for admins to restart their processes. I don't
think that's something musl should care about.
--
Laurent