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

[Brooks Harris]

On 2014-01-17 04:06 AM, Zefram wrote:

> Brooks Harris wrote:

>> I'll suggest a tentative name of this new timescale - "Common

>> Calendar Time (CCT)".

> Decent name.


Hi Zefram,

Thanks for the response. I'll take this as an encouraging sign there is 
merit to the idea.


>> B) Extrapolate an SI (1hz) timeline into the indefinite past,

>> essentially declaring TAI and UTC proleptic timescales

> You're conflating two different kinds of time scale here.  We have a

> theoretical ideal time scale that by definition ticks perfect SI seconds:

> Terrestrial Time (TT).  (Actually we have several such time scales, for

> different relativistic reference frames; TT corresponds to an observer

> on the rotating Terran geoid.)  TT is defined not just for the present

> but also, proleptically, as far back as we care to go.  Or at least as

> far back as the Earth has a well-defined surface.

>

> TAI (and hence, modulo the labelling of the seconds, UTC) does not

> tick perfect SI seconds.  TAI is the product of atomic clocks: it is

> our attempt to technologically realise the theoretical TT.  We know

> it doesn't perfectly match TT, and we have estimates of the errors.

> TAI is steered in frequency to match TT, but not steered in phase, so

> errors accumulate.  As it happens, since the TT/TAI synchronisation the

> errors have been consistently in one direction.

>

> TAI was essentially defined in mid 1958, when the atomic second was

> defined and the 1958-01-01 synchronisation to UT2(USNO) was determined.

> TAI can be extended backward proleptically, and in fact that 1958-01-01

> epoch is a proleptic TAI time.  But, by definition, TAI can only be

> extended as far back as there have been atomic clocks participating in

> synchronisation activities: that is, to mid 1955.

>

> So if you want a time scale that corresponds to TAI in the present

> and extends back proleptically, you have to make an awkward choice.

> Either you make it consistently match TAI and only extend back to 1955,

> or to extend back further you have a two-part definition that switches

> between a TT basis and a TAI basis sometime between 1955 and the present.

> Or there's another option: you could formally use a TT basis for all time,

> with the downside that in the present it diverges slightly from TAI.


The idea behind "CCT" is to better define "civil time". At root of this 
is UTC, and UTC is defined in terms of TAI. I consider 
1972-01-01T00:00:00Z (UTC) = 1972-01-01 00:00:10 (TAI) the mother all 
"epochs" in that realm, the beginning of modern "civil" time-keeping.

The mapping between TT and TAI is known, so by using TAI in the 
timescale we have implied this connection. There could certainly be an 
explicit statement about this fact if we wanted.

The point of declaring both UTC and TAI as proleptic before (exactly!) 
1972-01-01T00:00:00Z (UTC) is to create a proleptic 1hz timescale in 
phase with that crucial UTC/TAI date-time. With that we can define 
unambiguous Second offsets to existing timescales that have origins 
predating 1972 where that is possible. This is especially important 
where the POSIX "the Epoch" and the NTP "prime epoch" are concerned.

The motivation behind this is to help improve modern time-keeping, 
meaning, today, "digital" timekeeping. This comes in all sorts of shapes 
and sizes - computers in general, networks, file-time stamps, real-time 
OSs, firmware and hardware implementations, etc. as well as a host of 
computer languages. I'm sure we won't forget that main-stream OSs 
(Windows, Linux, OS X, Android, etc.) are event-driven multi-threaded 
OSs - they are not real-time. This throws another level of "be careful" 
into the conversation.

The legacy of these technologies has been discussed on the list a lot. 
Most computer time-keeping has descended in one way or another from 
"Uniix time" or "POSIX time". (By the way, its said these are the same, 
but I don't know of any official statement to that effect. I take it to 
be the case for now, but somebody ought to say so with authority sometime.).

Unix/POSIX time has its problems and these have rippled into many digtal 
time--keeping systems. As far a I can see, these difficulties are partly 
to blame, perhaps the main cause of, the "kill Leap Seconds" debate.

A central problem is the definition of the POSIX "The Epoch". As 
discussed, the specification is intentionally vague on this point to 
accommodate existing legacy systems.

We need to ask "When (the heck!) was "January 1, 1970 Coordinated 
Universal Time (UTC)." "? That "date-time" falls *before* the moment of 
1972-01-01T00:00:00Z (UTC), so it exists in the non-integral Seconds 
portion of the UTC/TAI history.

If we treat both the TAI and UTC timescales as proleptic before 
1972-01-01T00:00:00Z (UTC) = 1972-01-01 00:00:10 (TAI) we sweep the 
historical values of UTC/TAI under the rug. With this we can place the 
POSIX "the Epoch" at 1970-01-01T00:00:00Z on the proleptic UTC 
timescale, exactly 63072000 Seconds before 1972-01-01T00:00:00Z (UTC). 
This is 2 years on the uncompensated Gregorian calendar - (2 years * 365 
days * 86400 Seconds = 63072000).

We can look to the NTP specification to confirm this is how many 
computer systems treat time-keeping. The NTP "prime epoch" is explicitly 
placed on a proleptic UTC timescale before 1972-01-01T00:00:00Z (UTC) 
and also defines its relationship to "Unix-time" -

+-------------+------------+-----+---------------+------------------+

| Date        | MJD        | NTP | NTP Timestamp | Epoch            |

|             |            | Era | Era Offset |                  |

+-------------+------------+-----+---------------+------------------+

| 1 Jan 1900  | 15020      | 0   | 0             | First day NTP    |

| 1 Jan 1970  | 40,587     | 0   | 2,208,988,800 | First day UNIX   |

| 1 Jan 1972  | 41,317     | 0   | 2,272,060,800 | First day UTC    |


Figure 4: Interesting Historic NTP Dates

The NTP spec thus places the POSIX "the Epoch" in exactly the same place 
as proposed in CCT.

This is the important connection between computer time-keeping and the 
new timescale. The legitimacy of CCT as I've suggested it really hinges 
on that definition.

-Brooks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140117/984d528d/attachment.html>