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

[Brooks Harris]

On 2014-01-15 11:36 PM, Steve Allen wrote:

> On Thu 2014-01-16T06:55:00 +0000, Clive D.W. Feather hath writ:

>> Poul-Henning Kamp said:

>>> What *has* been proposed, where I have seen it, is to remove

>>> leap-seconds, and leave the "keep civil time in sync with the sun"

>>> up to local governments who can mess with their timezones as they

>>> see fit.

>> Right. And of the proposals on the table, this is the one that seems to me

>> to be the most practical.

> This notion leaves open the question of the name UTC.  In particular,

> can the delegates to the ITU-R RA be persuaded to vote for a new

> version of TF.460 if they are aware that the new wording will change

> the legal definition of the word "day" in every country which has

> adopted UTC as its time scale?  Will the delegates from other nations

> simply reject a proposal which is rooted in and strongly pushed by the

> military needs of the USA?  Will the ITU-R even dare to allow such a

> risky vote that might result in their new recommendation being

> disregarded by countries which want to preserve the meaning of "day"?

> Or can the delegates only be persuaded to vote if the new TF.460

> clearly explains the tradeoffs and chooses a new name?

>


I think we need an entirely new timescale that encompasses UTC rather 
than attempt to change the name. With so many technical and legal things 
tied to that name I can't see how it can be changed. Further, it seems 
every component of existing timescales are too vaguely defined and/or 
their names are "loaded" with historical connotations, rendering clear 
meaning and agreement nearly hopeless.

I think this calls for a completely new timescale, with 
reverse-compatibility to existing timescales, especially TAI and UTC, 
and with clear definitions of terms and counting-method rules. This 
could consolidate the fractured specifications into a comprehensive 
whole and TAI and UTC would then be cast into a new context. The ITU, 
technical protocols, and law everywhere could then adopt the new 
timescale at their leisure.

I'll suggest a tentative name of this new timescale - "Common Calendar 
Time (CCT)". Rationale:
- It is "date-time" everybody is interested in, which generally means 
"calendar", a concept missing from the UTC name.
- "Gregorian calendar" carries the old religious overtones and has some 
inadequacies where modern time-keeping is concerned.
- The new timescale defines the use of "Gregorian calendar counting" 
with additional counting methods to accommodate adjustments for earth 
rotation compensation
- "Common" is borrowed from "The Common Era" to avoid religious 
connotation, implies "common for the world", and implies "common link 
between timescales".
- Avoids the terms in the UTC name - "Universal", because its not 
universal; its Earth bound - and "coordinated", because its has become 
confused about what its coordinated with.

The main characteristics of the CCT timescale would be -

A) Correspond exactly to the *modern* definitions of TAI and UTC as of 
1972-01-01T00:00:00Z.

B) Extrapolate an SI (1hz) timeline into the indefinite past, 
essentially declaring TAI and UTC proleptic timescales before 
1972-01-01T00:00:00Z *regardless of their history before that moment*.

C) By declaring the anchor-point to existing TAI and UTC definitions as 
1972-01-01T00:00:00Z we have imposed an *uncompensated* Gregorian 
calendar counting scheme on the proleptic part of the new timescale, 
making 0000-01-01T00:00:00Z the origin of the new timescale. The 
intention is to sweep aside all time-keeping history regarding the 
calendar topic and make it a zero-based count.

D) Along the "modern" portion of CCT (after 1972-01-01T00:00:00Z), TAI 
and UTC continue to operate as they do today. The specification of CCT 
provides the opportunity to consolidate the fractured specifications of 
UTC and TAI into a comprehensive definition.

E) Because "Leap Seconds" are at the center of the "kill Leap Seconds" 
debate, because the methods of Leap Second insertion might be refined, 
and because methods of signalling "Leap Seconds" might be modernized, we 
also rename (our beloved) "Leap Seconds".

I'll hazard a suggestion - "Earth Correction".  Rationale:
- "Leap Seconds" doesn't communicate the fact that it is a compensation 
between the Earth rotation and atomic time
- Leap Seconds don't (theoretically) only "leap" - they could also "drop"
- "leap" confuses non-technical people
- "correction" is more widely understandable than "compensated" or some 
more technical term.

F) Along the CCT timescale we declare exactly where other important 
origins of conventional timescales exist -

-----------------------------------------------------------------------------------------
Origin      |  UTC1972    | Coincides   |          UTC |Leap|        TAI
Name        |  Seconds    | with        | |Secs|
             |  Offset     | Origin of   |                   ( Earth  )
             | |             |                   (Correction)
             |             |             |              |    | 
-----------------------------------------------------------------------------------------
UTC1900     | -2272060800 | NTP         | 1900-01-01T00:00:00Z | 10 | 
1900-01-01 00:00:10
TAI1958     |  -441763210 | TAI         | 1957-12-31T23:59:50Z | 10 | 
1958-01-01 00:00:00
TAI1970     |   -63072010 | 1588/PTP    | 1969-12-31T23:59:50Z | 10 | 
1970-01-01 00:00:00
UTC1970     |   -63072000 | POSIX       | 1970-01-01T00:00:00Z | 10 | 
1970-01-01 00:00:10
TAI1972     |         -10 | UTC + 10s   | 1971-12-31T23:59:50Z | 10 | 
1972-01-01 00:00:00
UTC1972     |           0 | UTC         | 1972-01-01T00:00:00Z | 10 | 
1972-01-01 00:00:10
UTC1972_7_1 |   +15724800 | First Leap  | 1972-07-01T00:00:00Z | 11 | 
1972-07-01 00:00:11
UTC1980_1_6 |  +252892800 | GPS Epoch   | 1980-01-06T00:00:00Z | 19 | 
1980-01-06 00:00:19
-----------------------------------------------------------------------------------------

G) We declare a new time axis that corresponds to the conventional 
"Offset from UTC" portion of "timezones" to separate the "time domain" 
aspect from the geographic aspect of "timezone" . This also decouples 
the technical behavior of the CCT timescale from political influence. It 
defines *only* the offset from CCT, with no connection to longitude of 
region.

I'll suggestion a name for this scale - "Local Time Offset (LTO)". Local 
Time Offset declares 104 offsets from CCT on 15 minute increments from 
CCT-12:00 to CCT+14:00.

CCT-12:00, CCT-11:45, CCT-11:30, CCT-11:15, CCT-11:00, CCT-10:45,....
CCT-00:30, CCT-00:15, CCTZ00:00, CCT+00:15, CCT+00:30, ....
CCT+12:45, CCT+13:00, CCT+13:15, CCT+13:30, CCT+13:45, CCT+14:00

While the intention is to decouple this time scale from geographic 
location. the offset correspond to conventional UTC+-XX:XX offsets. Thus 
the 104 offsets encompass all existing "timezone" offsets, such as 
within tz database. Many of the xx:30 and xx:15 segments are not 
currently used. Any implementation or local authority remains free to 
subscribe to any one of the offsets, but the CCT timescale is freed from 
responsibility to those external decisions.

H) We define a "Nominal Day" to accommodate the nine possible lengths of 
the day, depending on instantiation of Earth Correction (Leap Seconds) 
and Daylight Savings -
------------------------------------------------------------------------------------
Positive  | Negative  | Daylight| Daylight| hh:mm:ss | Seconds length
Earth     | Earth     | Onset   | Retreat | representation of last | of 
Nominal Day
Correction| Correction|         |         | Second of Nominal Day |
Insertion | Insertion |         |         | |
------------------------------------------------------------------------------------
      -    |     X     |    X    |    -    | 22:59:58 |  82799
      -    |     -     |    X    |    -    | 22:59:59 |  82800
      X    |     -     |    X    |    -    | 22:59:60 |  82801
      -    |     X     |    -    |    -    | 23:59:58 |  86399
      -    |     -     |    -    |    -    | 23:59:59 |  86400
      X    |     -     |    -    |    -    | 23:59:60 |  86401
      -    |     X     |    -    |    X    | 24:59:58 |  89999
      -    |     -     |    -    |    X    | 24:59:59 |  90000
      X    |     -     |    -    |    X    | 24:59:60 |  90001
------------------------------------------------------------------------------------

I've tried to highlight important aspects of what I think a new 
timescale should be. There are other details required, of course.

My hope is a new timescale would not obsolesce UTC, but instead augment 
and extend it to include modern time-keeping requirements. Perhaps its 
possible to informally hash out some common understanding to help sculpt 
a design that might later be more formally adopted by some credible 
organization, such as AAS. From there, perhaps it might find its way to 
ITU for consideration as a comprehensive framework in which to 
reconsider the "kill Leap Seconds" question.

I will now duck behind the podium in hope of avoiding direct hits from 
incoming projectiles.

-Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140116/5cdbf19f/attachment.html>