[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131127184307.GN1685@port70.net>
Date: Wed, 27 Nov 2013 19:43:07 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add support for leap seconds in zoneinfo files
* Laurent Bercot <ska-dietlibc@...rnet.org> [2013-11-27 05:53:28 +0000]:
> * the point of using TAI-10 instead of UTC is to have a linear system
> clock, so leap seconds must not be applied to clock_gettime() and
> friends.
TAI is non-linear for every moving object in the universe
it's wobbling and inaccurate like UT1 just on a smaller scale
the mistake was made in 1972 to broadcast leapsecond adjusted
atomic time for civil usage (UTC) instead of the earlier elastic
seconds (UT1) based on the rotation of the earth or plain SI
seconds (TAI,GPS,..) with deltaT information for display
there is an effort to redefine UTC though
http://www.ucolick.org/~sla/leapsecs/
> To sum it up:
> - leap seconds break POSIX anyway, but should break as little as possible
> - leap second users only care about system clock time, not broken-down time
> - so gmtime() should always return UTC, this is relied on by userland so
> it's more important than the exact relationship between tm and secs
> - so time() should ignore leap seconds but broken-down time should apply them
> - so the right place to apply them is in __secs_to_tm and __tm_to_secs, the
> conversion routines
> - using a posix/ zone will make everything POSIX in any case.
i think with the leap second patch localtime is no longer correct:
__secs_to_tm((long long)*t - tm->__tm_gmtoff, tm) < 0
the leap second will be added at the wrong time
(briefly making gmtime - localtime != gmtoff)
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.
