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