[LEAPSECS] Civil timekeeping before 1 January 1972

[Tom Van Baak]

Brooks wrote:
>> Many timekeeping systems seem to be designed for only indicating "now"
>> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
>> avoid supplying full Leap Second and local-time metadata.

Warner wrote:
> A clock doesn’t need to know its past. But a time scale is more than just how
> many seconds the current minute will have. It has a history and to compute
> elapsed time in that time scale, you need to know its history.

Ok, thanks. So there's a terminology issue among Brooks' "timekeeping system", Tom's "clock", and Warner's "timescale".

I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a UTC synchronization algorithm. UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a timescale. There are clock ensemble algorithms. There are time transfer methods. There are time encoding conventions. There are time API's in languages, libraries, or operating systems.

WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST). GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO).

I'm not trying to pick a fight here. Just trying to seek clarification. I guess I still don't understand what Brooks is trying to "sell", or why full historical phase or frequency records are any part of timekeeping, or time transfer.

Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further provide to satisfy your clientele? Must you rely on hardcopy historical journal articles, on-air data, or web-based tables to satisfy your timekeeping requirement?

I do a lot of timekeeping here, old and new. What time_t looked like before 1972 is not a problem. Yes, civil timekeeping (before or after 1972) is an interest to me. But all the older stuff arrives in the form of faded paper, or JPG photos, or TXT files. I would never think of trying to encode that into some 32 or 64 bit binary format.

/tvb