Date: Tue, 20 May 2014 21:36:53 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Post-1.1.1 plans On Wed, May 21, 2014 at 02:01:03AM +0100, Laurent Bercot wrote: > >There may be other open things I'm missing; let me know if you have a > >request that doesn't appear above. > > I would like to have a serious design discussion about how to implement > leap second support in musl. I haven't taken the time to have a serious > go at it since I first mentioned it, but I have thought about it for a > bit and it is indeed more complex than it appears - because the standard > way of supporting them, i.e. in timezone files, is broken. (Timezones are > a process-wide setting since the default can be overriden with TZ, but > interpretation of the system clock as a TAI or UTC clock should be a > system-wide setting.) > So, before diving in and writing some more code that won't be merged in, > I'd like to assess exactly what would be acceptable for musl and what > would not. > > A probable spin-off of this discussion is a subject in itself: what would > be an acceptable format, a set of conventions to follow, to add > musl-specific extensions outside of POSIX (or whatever superset of POSIX > musl implements). I really don't know. My recollection from the previous thread was that we kept running into situations where the behavior would be non-conforming. I've since been told by glibc developers that, on glibc, setting TZ to a zone with leapseconds results in a discrepency between the results of gmtime() and localtime() -- they don't differ just by the local offset but also by the leap seconds offset. If correct, this is obviously atrociously bad behavior, but at least it seems to be conforming. So I don't really know what to tell you. As you know I'm rather an anti-fan of leapseconds/TAI, so while in some ways it's an interesting and challenging problem, it's not something I'm really excited about spending my mental energy on. Probably in the short term, the best thing you can do is keep whatever patches work for you; it's fine to link them on the wiki, and it would be great to document what properties of libc they affect (e.g. thread-safety of interfaces, functions that newly depend on environment, etc.). This would also help in evaluating whether the patches would eventually be acceptable upstream. I also really question whether there's a superior kernel-based approach to the transformation of time_t. I haven't read it in detail, but there's a thread here that may be relevant: http://lkml.iu.edu//hypermail/linux/kernel/1205.2/01644.html If this interface was committed and works, the way to configure leapseconds for the libc time_t conversion layer might be simple: ask the kernel how the system clock is configured. That's certainly cleaner than having environment variables and inconsistent per-process settings. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.