[LEAPSECS] Time math libraries, UTC to TAI

GERRY ASHTON ashtongj at comcast.net
Fri Jan 6 14:29:35 EST 2017


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


More information about the LEAPSECS mailing list