[LEAPSECS] Civil timekeeping before 1 January 1972

[Warner Losh]

> On Mar 7, 2015, at 4:50 PM, Joseph Gwinn <joegwinn at comcast.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150308/13545c7d/attachment.pgp>