[LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

Keep in mind that leap seconds have a short shelf life. Over the next
1000 years, it's projected TAI - UT will grow to about an hour
(2500-4500 if I'm reading
https://www.ucolick.org/~sla/leapsecs/deltat.html right). In two
thousand it will be about 4 hours due to quadratic acceleration.
That's ~10k seconds in 1k years, or about one per month. The current
UTC spec will run out of steam long before then, as it defines only 4
times to insert leap seconds (well, 4 preferred times, any month can
be victim). Needing 12 per year means we're driving at about 1s/month
which means that keeping DUT1 to < 0.9 will be a challenge due to
seasonal variation and such. The Nyquist limit suggests that we'll run
out of steam when we hit one every 6 months, which would be about
~1200 years from now (give or take a few hundred, there's a lot of
uncertainty in the long term rate). Some new means of synchronization
must be found, the only real question is when. Well before that date,
letters from BIPM/IERS will cease to cut it (I'm in the camp that says
we're already past that date: no reliable[*] means to get leap seconds
exists today from authoritative sources).

Warner

[*] By this I mean some non-forgeable, authoritatively signed by
BIPM/IERS table of leap seconds, automatically updated and an
official, guaranteed service of the agency.

On Fri, Jan 6, 2017 at 12:29 PM, GERRY ASHTON <ashtongj at comcast.net> wrote:
> The Gregorian calendar and UTC with leap seconds are in harmony; the customary change-of-day time with the Gregorian calendar is midnight, and the methods used to establish midnight throughout most of the time the Gregorian calendar has been in use did not approach accuracy of tens of seconds. It is TAI or other 86,000-SI-seconds-per-day time scales that will not be in harmony with the Gregorian calendar in hundreds or thousands of years when the difference between mean solar time and 86,000-SI-seconds-per-day time scales becomes appreciable ("appreciable" literally being a religious issue).
>
>> On January 6, 2017 at 5:50 PM Brooks Harris <brooks at edlmax.com> wrote:
>>
>>
>> On 2017-01-05 09:33 PM, Steve Summit wrote:
>> > Brooks Harris wrote:
>> >> It seems to me infeasible to alter the basic behavior of time_t
>> >> because it effects every aspect of the operating system,
>> > Absolutely.  Posix time_t is untouchable, and here to stay.
>> >
>> >> POSIX time and 86400-second-day systems (including Windows time) will
>> >> never exactly  match UTC at the Leap Second and we'll have to live
>> >> with that partial inaccuracy for a long time.
>> > Right.  (But I don't know if people will find the inevitable
>> > discrepancies between time_t and "Time2" acceptable.)
>> That's been at the heart of the "eliminate Leap Seconds debate", right?
>> Two camps, basically. But given both UTC with Leap Seconds and Gregorian
>> as inevitable conventional circumstances its no longer a question of
>> acceptable or not. It is what it is, so lets agree how best to support
>> the two with the least inaccuracy, least complexity, and least
>> disruption to existing systems. It can't be perfect; the two just do
>> not, and will not, match. There's not enough holes in Gregarian to
>> accommodate the Leap Second pegs.
>>
>> >
>> >> But a second, parallel, time system (call it POSIX Time2) could
>> >> implement a fixed-epoch timer (call it time2_t) and a
>> >> Leap-Second-accurate API that would yield YMDhms representation
>> >> including 23:59:60, call them, for examples, gmtime2() and mktime2().
>> > That's essentially what clock_gettime(CLOCK_UTC) gets you.
>> > A struct timespec fetched with clock_gettime(CLOCK_UTC) is your
>> > "POSIX Time2".  I have implemented gmtime_ts_r() and mktime_ts()
>> > which operate on struct timespec, and do the right thing with :60.
>> Ah good.
>>
>> What source are you using for the Leap Seconds? Tz Database?
>>
>> >
>> >> With that, those applications that needed it could use the POSIX Time2
>> >> API, and everybody else would be none the wiser. It would also define
>> >> the mapping between legacy POSIX and the UTC-accurate POSIX Time2.
>> > That's exactly my intent, and I have it all working on my test
>> > system today.  Just one or two more bugfixes and I should be
>> > ready to post it!  (I've been saying for the past several months.)
>> Its a harder problem than it appears, as those of us who've got our
>> fingers dirty with the implementation details can attest. Going at it
>> directly in the OS takes guts :-)
>> >
>> >> Eventually, maybe the file system timestamps could be augmented with
>> >> flags to mark Leap Second instances and local time parameters.
>> > I'm not ready to think about the filesystem yet (beyond thinking
>> > that leapsecond-aware filesystem timestamps don't seem nearly as
>> > important).
>> I think the challenge inevitably arrives at the file system(s), so a
>> comprehensive plan should anticipate how that could eventually be
>> accomplished. This is related to Harlan's "General Timestamp API"
>> project, I think.
>> > First I've got to get non-UTC timers (i.e., almost
>> > all of them) working properly in the face of smeared time, and
>> > that's going to be plenty hard, and then some.
>> Yes, this looks like it could create severe brain damage.
>>
>> -Brooks
>>
>> > _______________________________________________
>> > LEAPSECS mailing list
>> > LEAPSECS at leapsecond.com
>> > https://pairlist6.pair.net/mailman/listinfo/leapsecs
>> >
>> >
>>
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs