[LEAPSECS] Civil timekeeping before 1 January 1972

[Joseph Gwinn]

On Sun, 08 Mar 2015 12:24:42 -0400, Brooks Harris wrote:
> 
> On 2015-03-07 06:50 PM, Joseph Gwinn wrote:
>> On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
>>> 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.
> Hi Joe,
> 
> I see the difficulties with UTC implementations and the questions at 
> ITU-R stemming from the historical and legacy misalignment of the 
> timekeeping mechanisms of the c language and POSIX and the UTC 
> specifications. Perhaps that's obvious. I'm not criticizing anybody 
> anywhere for this, its just the way its come about.
> 
> I think the only way the industry can eventually converge on reliable 
> "civil time" representation is to refine the underlying time 
> mechanisms in POSIX in some manner that allows a migration to a more 
> comprehensive UTC implementation. I think if a new new POSIX time 
> specification were to take shape it would add an option to the the 
> conversation at ITU-R - instead of simply "to kill Leap Seconds or 
> not" they'd also have "a viable migration path to comprehensive UTC 
> timekeeping implementation" to consider.
> 
> We understand the folks at POSIX have grappled with this topic in the 
> past and run into all sorts of difficulty. Given the current state of 
> affairs, do you think there's any way IEEE and POSIX could reengage 
> this topic?

The biggest problem was that the time folk couldn't stop arguing, and 
come to a solution that met all of POSIX's technical requirements.  Nor 
should the arguments be held in the POSIX committee, most of which were 
totally unable to follow the arguments.  The committee finally threw 
the time folk out into the snow and settled for minimal changes.  I did 
get the statement that each day has exactly 86,400 seconds written into 
the standard, and that although it resembled UTC is was not in fact 
UTC, to cut off the common misinterpretation that POSIX time was UTC.  
I published the email threads some time ago.  Anyway, if the time folk 
could come to agreement and present one proposal, there is a chance.

Also listed in the email threads were the requirements, and one of the 
requirements is that POSIX time had to work in a reasonable way even in 
totally isolated systems, which have no way to know about leap seconds.

Joe Gwinn