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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
