[LEAPSECS] Common Calendar Time (CCT) - timescale design -Brooks Harris

[Zefram]

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 were recorded prior to 1972, and
time_t is used more widely to represent times that do not correspond
to any recorded timestamp and which sometimes significantly precede
the origin.  The interpretation of ancient Unix timestamps is more of
a historiographical pursuit than a mathematical one.  Where time_t is
used for other purposes, the interpretation of time_t values depends
rather on the application, which must essentially pick a time scale,
and this seems to be the only place of those you've referred to where
there's any possible use for your new time scales.


>Anterior Common Calendar Time (ACCT), defined as a 1Hz scale before

>1972-01-01T00:00:00Z (CCT).

>Anterior Proper Atomic Time (APAT), defined as a 1Hz scale before

>1972-01-01 00:00:10 (PAT).


What do you mean by "a 1Hz scale"?  In the present context, with multiple
time scales being relevant, if you're trying to describe a frequency
then you'd better augment the quantity with a reference time scale,
or at least a relativistic reference frame.  But "a <frequency> scale"
still doesn't mean much.  What would a 1.5 Hz scale be?

It is conventional to describe synthetic time scales by means of
(pseudo-)arithmetic expressions in terms of other time scales.  You say
they're not defined precisely, so presumably you can't do this in the
usual way.  If they're approximate, perhaps you could characterise them
by inequalities ("f(TT) <= APAT <= g(TT)").  If purely notional, you
should at least specify what kind of timestamps arise in the time scales.
For example, can ACCT contain leap second events?

It looks like your intent is for ACCT to coincide with CCT as 1972-01-01
00:00:00, and similarly for APAT to link up with PAT, but you don't
actually say this.  Defining arithmetic expressions would help here.

Are ACCT and APAT defined for times after the 1972 epochs that you listed?
This is linked to the earlier note about CCT and PAT not being defined
prior to 1972.

You intend ACCT and APAT to have a defined relationship to each other.
You should say what this relationship is, again using an arithmetic
expression if possible.  This relationship can serve to define one of
these time scales if the other is defined by other means.


>                         ACCT and APAT are defined in terms of CCT

>and PAT to retain the distinction.


What distinction are you making (or retaining) here?  As you defined
CCT and PAT to be identical to UTC and TAI from the 1972 epoch onwards,
you could have equivalently referred to UTC or TAI to describe the 1972
epoch when defining ACCT and APAT.


>Leap Seconds are renamed Earth Corrections. Earth Corrections behave

>identically to Leap Seconds after 1972-01-01T00:00:00Z (UTC) =


This time round you have definitely screwed up the terminology here.
This paragraph uses "Earth Correction" to refer to leap second events,
but the table a bit later uses "Earth Correction" to refer to the
difference between ACCT/CCT and APAT/PAT.  You should not use one term
for both meanings.  A "correction" sounds more like it would refer to
the difference.  If you want to rename leap seconds, you therefore need
another term for the events.  As I noted previously, you don't have a
good rationale for renaming them.  They're not going to get any less
controversial by being respelled.


>                Prior to 1972, Earth Corrections are artificially

>applied to properly adjust the alignment of the NTP and Unix/POSIX

>origins to 1972-01-01T00:00:00Z (CCT).


This needs explanation.  Your table still shows no leap events prior to
1972, so this statement that they are applied prior to 1972 appears to
be false.  I can't make any sense of the "adjust the alignment" part.

In the table, your "CCT1972 Seconds Offset" is not accurately described
as a "seconds offset".  It behaves the same as NTP and Unix scalar
time values, counting 86400 per ACCT/CCT day, and thus not counting
leap seconds.  There is no gain to be made by defining yet another fake
seconds count with yet another epoch.


>Comments welcome.


Overall, the exercise seems profoundly pointless.  Your stated primary
objective, of fresh definitions of TAI and UTC, is not addressed at all
by what you've posted.  You don't add anything to our understanding of
the NTP, PTP, or Unix epochs, which you state is your second objective.
All you can achieve in this regard by creating a pre-1972 leap schedule
(whether empty or otherwise) is to allow the NTP epoch's fictitious
UTC timestamp to be translated into an equally fictitious pseudo-TAI
timestamp, which cannot have any relevance to real NTP computations.

Your APAT has no advantage over TAI.  All you're doing is providing a
notional time scale in which one can perform purely formal computations
that have no connection to real instants.  That need, where it exists,
is already satisfied by the possibility of computing with fictitious
TAI timestamps.  You have not added anything to this kind of system.
Furthermore, by using a 1972 switch between notional and real time scales,
the APAT/PAT structure obscures some 16 years of usable real TAI.

Your ACCT, as previously noted, makes a poor proleptic extension of UTC,
by virtue of not tracking UT1.  By renaming it from "proleptic UTC"
you at least avoid misrepresenting it, but with the ACCT/CCT structure
you still intend it to be used as a proleptic extension of modern UTC.
In situations where the leap seconds are insignificant, ACCT adds nothing
to the practice (as seen with NTP and some interpretations of POSIX)
of formal computation with fictitious UTC timestamps.  Where the leap
seconds are significant, having none is detrimental to accuracy.

Your definitions are generally poor.  There is much that you omit or
make horrendously unclear.  There's a definite skill to writing usable
technical specifications, and you don't have it.  In the light of this,
it would be unwise for you to tackle your stated primary objective of
new definitions to supplant TAI and UTC.  It is conceivable that you
could develop this skill in time, but not a short time.

As for other parts of CCT, you're mixing together too many things under
the CCT banner.  Timezones are a separate concern from time scales
such as UTC.  The calendar is another completely separate concern; none
of the time scales here is especially tied to the Gregorian calendar.
(UTC has a Gregorian-based rule for when leap seconds are permitted,
and significant epochs tend to be on Gregorian year boundaries, but
generally describing days by MJDN works perfectly well.)  Even looking
just at your two time scales, they're logically fairly distinct concerns,
and the definitions have suffered from you tackling both together.
You are treating in the same way things that have relevant differences,
not giving each the individual attention that it needs.  To produce
better results you need to tackle narrower subproblems.

-zefram