Brooks Harris wrote:
The main objective of the CCT design is to recast TAI and UTC into a
more unified specification appropriate for time-keeping from 1972
onward.
Just so we're clear about scope, your message doesn't actually respecify
TAI and UTC. You've defined your PAT and CCT, for the post-1972 era,
as being equivalent to TAI and UTC, referencing the existing definitions
of TAI and UTC. I presume that your intent is to later replace these
references, instead defining PAT and CCT in a way that's equivalent to
the current definitions of TAI and UTC without referring to them.
It does not represent accurate date-time prior to 1972.
You're defining pre-1972 time scales, but they're rather insipid if they
don't have any well-defined relationship to actual pre-1972 events.
defines the relationship of other important timescales to TAI and
UTC.
Defining new time scales doesn't affect the relationship of anything to
the existing TAI and UTC. Is this a stray reference that you meant to
change to refer to your new time scales?
Common Calendar Time (CCT), defined as Coordinated Universal Time
(UTC) after 1972-01-01T00:00:00Z (UTC).
Proper Atomic Time (PAT), defined as International Atomic Time (TAI)
after 1972-01-01 00:00:10 (TAI).
As far as I can see, you're not defining these time scales at all for
pre-1972 times, that role being taken by ACCT and APAT. Is that your
intent? The kind of use you seem to intend for them suggests that you
actually want a single pair of time scales that are defined both before
and after 1972, with some kind of continuity. In each case, it would
be better to have a single name for the hybrid time scale that covers
both eras.
The second important aspect of the design is to explicitly define the
offsets of important timescales to 1972-01-01T00:00:00Z (UTC) and
1972-01-01 00:00:10 (TAI), in particular to the origins of NTP,
1588/PTP, and Unix/POSIX.
Your reference to offsets here is unclear. It could mean numbers
of seconds on some time scale, but you don't say which one. The exact
nature of the following critique depends somewhat on what kind of offsets
you have in mind.
In general, defining new time scales doesn't affect existing definitions
that refer to TAI and UTC. You can't make any of the poorly-defined
systems any better defined, unless you get their specs changed to refer
to your new time scales. Absent that, the most you can possibly do is
to provide a new way to work with the existing systems.
As I've previously noted, the origin of NTP is a fictitious UTC timestamp,
which does not attempt to refer to a particular real instant. The offset
in NTP scalar time values between the origin and modern UTC timestamps
(except in the immediate vicinity of leap seconds) is well defined by NTP,
and is in no need of further definition. Computing an offset between
the NTP origin and a modern time on any other time scale would be inane.
Due to the fictitious nature of the origin, it is not possible to compute
any offset on any time scale that has a well-defined relationship to
real events. Any offset that can be computed in a well-defined way would
necessarily be just as fictitious as the offset obtained by subtracting
NTP scalar time values.
I'm not familiar with PTP, but I see a number of documents saying that it
uses an epoch of 1970-01-01 00:00:00 TAI. If so, unlike the NTP origin
this is a perfectly well-defined real instant. TAI offsets between
this epoch and modern timestamps are well-defined and well-behaved,
with the simple sexegesimal relationship between second counts and
broken-down timestamps. Any new time scale you apply to this situation
will produce results that are at best equivalent to this. But in
any case, PTP doesn't need offsets from the epoch to be well-defined.
As with NTP, being a synchronisation protocol, it only needs its time
values to have well-defined meaning for current times, and to process
differences between current times.
Your inclusion of PTP here suggests that you're under the impression that
TAI has some definitional defect prior to 1972, in parallel with UTC.
That is not the case. TAI is well defined back to some time in 1955,
and has most of its present features throughout its span. There is
one relatively significant historical change in its behaviour: the
introduction of corrections for gravitational time dilation at 1977-01-01
00:00:00 TAI. Prior to that, TAI ran a bit fast, relative to how it's
steered today, due to the atomic clocks being above sea level. (Since
then it's almost always run a (much smaller) bit slow, for other reasons.)
With the Unix epoch, yet again there is no great need to process
offsets spanning the origin. The interpretation of modern time_t
values is not affected by the precise definition of the origin.
(There are multiple interpretations of time_t within the Unix tradition;
I'm not only referring to the POSIX spec here.) Unlike NTP and PTP,
there are actual Unix timestamps that