[LEAPSECS] Civil timekeeping before 1 January 1972
joegwinn at comcast.net
Sat Mar 7 18:50:40 EST 2015
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
>> 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
> 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.
More information about the LEAPSECS