[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131205142102.GZ1685@port70.net>
Date: Thu, 5 Dec 2013 15:21:02 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
* Laurent Bercot <ska-dietlibc@...rnet.org> [2013-12-05 08:58:50 +0000]:
> This is true if and only if all leap seconds are 1, which is the case for now
> and in the foreseeable future, but my version supports even the improbable
> case where different corrections are introduced.
"The current rules for leap seconds in UTC are specified by ITU-R TF.460.
They state that a leap second may be added (or subtracted) at the end of
any month, but that first preference is given to June and December, and
second preference is given to March and September."
this breaks down after <2000 years when there will be 12 leapseconds/year,
allowing 1 leapsecond/day will work for >40000 years
the UTC definition does not allow double leap seconds so posix and
iso c specify the [0,60] range for tm_sec (ie >1 leap seconds cannot
be supported, <-1 leap seconds could be supported, but since the
earth slows down that wont happen)
systems will not break because a big leap is introduced 10k years from
now, but because there is a day with 86401 seconds about every 2 years
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.
