[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
