[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Nov 2013 18:05:15 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Pending patches/issues before 0.9.15 release?
On Thu, Nov 21, 2013 at 11:54:41PM +0100, Szabolcs Nagy wrote:
> * Laurent Bercot <ska-dietlibc@...rnet.org> [2013-11-21 19:27:53 +0000]:
> > The short version of what right/ timezones are is explained here:
> > http://www.madore.org/~david/computers/unix-leap-seconds.html#tai-minus-10
>
> according to the official tzdata code the "right/" directory
> is obsolete and different path is used for this now
>
> "The advantage of this scheme is that TAI−10 uniquely refers
> to an instant in time, and the difference between two such
> values determines the interval between these instants"
>
> is not true, a single time coordinate cannot uniquely refer to
> an instant in time (TAI only specifies the frame of reference
> since 1977, before that it was largely nonsense and after that
> it only measures the time somewhat accurately for observers at
> sea level in rest, but eg outside the gravity well of earth it
> is off by 22ms/year)
Indeed. Relativity is the main reason I find the argument for using SI
seconds as a calendar unit unconvincing. SI seconds are a sort of
"local coordinate system" in a particular inertial frame of reference,
whereas calendar time is a shared reference for coordinating human
(and computer) activity. In the latter, "days" are the basic
observable unit, and seconds are just a particular subdivision of
days. Having the number of seconds a day is divided into vary in a way
that *seems* arbitrary to 99.99999% of users of the system is not a
desirable property from my perspective.
> even in classical physics, a clock source with precise ticks is
> not usable for representing dates because the rotation of the
> earth is not exactly periodic (by which dates are defined)
My understanding is that TAI ignores this. The idea is to measure a
fixed physical time quantity that's not related to the human calendar
except for being closely approximated by the calendar second.
> > The difference between glibc and musl is 25 seconds, not 35 as I wrote,
> > which seems to indicate that musl's gmtime()/localtime() does not take leap
> > second tables, which are defined in right/ timezones, into account.
> > I would really love that to be fixed - maybe not for 0.9.15, but for 0.9.16
> > if possible, because I'm a hardcore TAI-10 user.
>
> knowing that TAI is non-conforming you need to provide a strong
> use-case for it
There seems to be some kernel-space effort for handling TAI, but I
have no idea if it's sane or not. Ideally the kernel would be able to
keep it while exposing smooth POSIX time to userspace via the default
clocks and TAI via the non-POSIX extension TAI clocks.
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.
