[LEAPSECS] Civil timekeeping before 1 January 1972

[Brooks Harris]

Hi Tom,

On 2015-03-12 09:50 PM, Tom Van Baak wrote:
> 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".
Oh yes, there sure are terminology issues all over the place. Its a 
frustration of mine - expert debate endlessly about details to finally 
discover they're talking about the same things in different term. 
Timekeeping is old, there's lots of terms. Keeping thing clear is a 
challenge.
>
> I didn't think that NTP or POSIX or PTP is what we'd call a timescale.
I do, I think.

I think of a timescale as having -
A) Some unit measure of time. Typically seconds, but could be some other 
convenient division of time.
B) Some origin or "epoch" - a "starting point" for counting, might be 
signed or unsigned.
C) Some "counting method" - as simple as uninterrupted incrementing 
count, or more complex like Gregorian for example

"Counting method" deserves more explanation. I use the term to encompass 
a couple concepts. A "counting method" could be a simple integer number 
counting scheme (0,1,2,3,...) or generate a more complex encoding like 
"1972-01-01T00:00:00". We've come to use the term "time related label" - 
a lable being an 'identifier' assigned to some particular item in a 
sequence of time-related units.

A "time related label" may be generated by the rules of *pure* Gregorian 
calendar counting method -

1972-06-30T23:59:59
1972-07-01T00:00:00

Or Gregorian calendar modified by UTC Leap Seconds counting method -

1972-06-30T23:59:59
1972-06-30T23:59:60
1972-07-01T00:00:00

These might be represented as "broken down time" ie: YY-MM-DD hh:mm:ss 
values.

There may be a corresponding absolute integer value for these seconds, 
like time_t. Here the "counting method" is a zero-based uninterrupted 
incrementing count, and each number is a "time related label" of each 
second.

Put another way, the "counting method" is the algorithm by which the 
time value is encoded as a time related label.

> NTP is a UTC synchronization algorithm.
Hmmm. Well, yes, I suppose. Hadn't thought of it that way.

If Leap Seconds are properly applied to it it effectively becomes many 
independent timescales because the epoch slips with respect to 
1972-01-01T00:00:00Z (UTC) with each Leap Second.

I think I'd say its an algorithm that synchronizes Gregorian calendar 
date and time representations with UTC. Of course its obviously flawed 
where the 23:59:60 count is concerned.

> UT0 is a measurement.
OK.
> UT1 is a timescale.
OK.
>   TAI is a timescale.
Yes - a timescale with a simple counting method - an uninterrupted 
incrementing count of  seconds
>   UTC is a timescale.
Yes - a timescale with a complex, irregular, and partly unpredictable 
counting method.
> 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.
Sure, and its important to keep the divisions between what we're talking 
about clear.
>
> WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST).
Yes, with a protocol for communicating the current UTC value along the 
UTC timescale.
> GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO).
Hmm. Right, well, GPS time is a timescale - time measure in seconds, 
epoch at 1980-01-06T00:00:00Z (UTC), counting method of uninterrupted 
weeks. While its epoch is referenced to UTC, its (primary) counting 
method is "TAI-like" - uninterrupted regular count. It is GPS time on 
the GPS timescale that is 'transferred', no?

>
> I'm not trying to pick a fight here. Just trying to seek clarification.
Thanks. I appreciate a productive conversation. The lexicon is always at 
the root of the misunderstandings. This is critical when gets to 
standards documents It has to be as clear and commonly understood as 
possible and agreed on. That's part of the difficulty with UTC, other 
timescales, and the whole subject of "time" - the documents are often 
written is very different terms making understanding and comparisons 
difficult.
> 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.
To calculate accurate time intervals (durations) and/or elapsed times.  
How many seconds between 1972-06-30T23:59:59Z (UTC) and 
1972-07-01T00:00:00Z (UTC)? *Two*. But to know that you need to know a 
positive Leap Second occured at 1972-06-30T23:59:60Z (UTC).
>
> Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further provide to satisfy your clientele?
It may not be practical to retrofit a metadata delivery channel into 
those protocols. But we need a reliable electronic means of obtaining - 
Leap Second announcements, "promised expiration", and the table of 
historical Leap Seconds. Basically Bulletin C and 
Leap_Second_History.dat 
(https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat)

(Not just *my* clientele - any accurate UTC system.)

> Must you rely on hardcopy historical journal articles, on-air data, or web-based tables to satisfy your timekeeping requirement?
I'm talking about automatic electronic acquisition of the metadata, the 
subject of recent postings about Rob Seaman's DNS scheme and Steve 
Allan's use of the "right" tz database approach.
>
> 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.
Date and time before 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 
(TAI) is more-or-less inaccurate or controversial by any measure and 
exist in eras when the names of timescales and historical values are 
controversial. I know there are very good reasons for particular 
purposes to represent date and times before the "UTC Leap Second Epoch", 
but not for practical timekeeping after this epoch.

-Brooks
>
> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs