> On Mar 7, 2015, at 4:50 PM, Joseph Gwinn <[email protected]> wrote: > > On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote: >> Hi Gerard, >> >> On 2015-03-07 12:04 PM, G Ashton wrote: >>> >>> Brooks Harris wrote on Saturday, March 7, 2015 11:50 : >>> . >>> . >>> "The challenge I'm trying to solve is to provide a deterministic >>> timekeeping >>> and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) = >>> 1972-01-01T00:00:10 (TAI). This is essentially the purpose of "civil time" >>> timekeeping as is typically intended....The timescale before 1972 is an >>> abstract proleptic Gregorian calendar scale for purposes of calculation >>> convenience. On this scale, like NTP, PTP, and POSIX, any date-time before >>> 1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid." >>> >>> Civil timekeeping is concerned with many things, including determining when >>> one date ends and another begins. Thus civil timekeeping is inextricably >>> linked to civil calendars. Although the time of day of past events become >>> less and less important as the decades pass, the date of those >>> events remain >>> important. Since some computer applications routinely attempt, in their >>> clumsy way, to account for timezones, timekeeping is potentially important >>> for the computer representation of timestamps, even when the humans using >>> the computer are only interested in the date. Of course, dates long before >>> 1972 are of interest in civil matters; dates of birth immediately come to >>> mind. >> I agree. >> >>> So when Brooks Harris presents his API to his stakeholders, I think a >>> more thorough explanation of why date-time expressions before 1972 >>> will be " >>> considered either inaccurate or invalid" will be needed. >> >> It is typically warned that date and time before 1972 cannot be >> accurately represented with NTP or POSIX, for examples. These >> timescale's origins precede 1972-01-01T00:00:00Z (UTC) = >> 1972-01-01T00:00:10 (TAI) and seek to represent date-time counting >> *forward*. They give no consideration to date-time accuracy before >> 1972, but operate on proleptic scales convenient for computation. >> This is generally true with widely available timekeeping services on >> OSs, systems, languages, and many typical applications because so >> many of them implement mechanisms based on the heritage of the POSIX >> timekeeping mechanisms, complete with its flaws with respect to >> representing UTC and Leap Seconds. >> >> In the discussions I've been involved with many people argued >> strenuously "we don't care about the past, only accurate date-time >> going forward!". The reason I'm choosing to ignore the subject of >> accurate date-times before 1972 is not that its not important, but >> probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS >> - its just too expansive a topic to tackle in some commonly accepted >> way. For date-time before 1972 you've got to switch to some other >> timescale depending on the purpose at hand. > > I figured it out the difference between GMD and UTC for POSIX. There > was an 81 microsecond error, At the time, most UNIX boxes kept time to > the nearest second, synchronized to a hairy wrist. There were advanced > systems that could do milliseconds, and in the 1980s a few that had > microsecond resolution, but we chained them to GPS via NTP, so the > error was multiple milliseconds, depending on everything.
Keep in mind that time-stamps come from things other than computers. So while this is an interesting footnote, it doesn’t describe the set of all timestamps. For a general purpose API, it has to encompass more than what a computer was capable of in the 70’s. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
