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
