Re: [PATCHv2] Add support for leap seconds in zoneinfo files

[Laurent Bercot <ska-dietlibc@skarnet.org>]

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