> musl supports the zoneinfo format, according to
> http://www.etalabs.net/compare_libcs.html
> So as long as it does, there's no reason why it shouldn't support
> the right/ timezones, which are zoneinfo timezones just like POSIX ones.
Follow-up on that.
musl does not support right/ timezones, and there's actually a good
reason for it.
Essentially, the configuration of the system clock (TAI-10 or UTC)
is a system-wide setting, whereas timezones are a process-wide setting -
the default timezone can be overriden with the TZ environment variable.
It is yet another case of broken standard: leap second handling should
not be performed at the same level as timezone handling. It's just not
the same.
(Part of me thinks the timezone should also be a system-wide
setting and not be overridable, but we're not going to get that standard
changed.)
So we need another mechanism to handle leap seconds, and the
skalibs mechanism, inherited from djb's libtai, actually isn't half bad.
The problem is what works for an application library doesn't
necessarily work for a libc that aims to respect standards without
adding nonportable extensions.
I'm still looking for a way to support TAI-10 clocks cleanly, but
I'm more and more convinced that the right thing is to get kernel
support. There is a CLOCK_TAI in the Linux kernel, but it doesn't do
what we want at all.
What we want is:
* an entry point to provide a leap second table to the kernel
* a CLOCK_TAI clock, writable as well as settable, and related to
CLOCK_REALTIME by way of the registered leap second table.
* an entry point to tell the kernel "now your linear clock is
CLOCK_REALTIME, just add leap seconds to it to get CLOCK_TAI" or
"now your linear clock is CLOCK_TAI, just substract leap seconds
from it to get CLOCK_REALTIME".
If we had this, our problems would be solved forever. Now getting
that into the Linux kernel will be hard, and I don't even want to
think about other kernels.
--
Laurent
Received on Wed May 21 2014 - 14:55:24 UTC