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 <[email protected]> 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 <[email protected]> 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 >> > [email protected] >> > https://pairlist6.pair.net/mailman/listinfo/leapsecs >> > >> > >> >> _______________________________________________ >> LEAPSECS mailing list >> [email protected] >> https://pairlist6.pair.net/mailman/listinfo/leapsecs > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
