[LEAPSECS] Common Calendar Time (CCT) - timescale design -Brooks Harris
I've renamed and reorganized the proposed timescales of CCT to reflect the responses I've gotten and to hopefully make the intentions clear. I had used the terms proleptic UTC and proleptic TAI and these are now renamed. There are other important elements the CCT proposal, including counting methods and local time, but this posting is limited to the topic of the primary timescales used in CCT. 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. It does not represent accurate date-time prior to 1972. In addition to maintaining reverse compatibility to TAI and UTC it also defines the relationship of other important timescales to TAI and UTC. The design intentionally sweeps aside the developmental history and historical values of TAI/UTC, defining two new 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). These map directly to the current definitions of TAI and UTC after 1972-01-01T00:00:00Z (UTC) = 1972-01-01 00:00:10 (TAI). 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. The design declares two scales that immediately precede the origins of CCT and PAT - 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). (These terms replace the earlier proleptic UTC and proleptic TAI). ACCT and APAT are both 1Hz timescales extending into the indefinite past. They are artificial constructions for computational convenience and have no accurate relationship to date-time before 1972-01-01T00:00:00Z (CCT) = 1972-01-01 00:00:10 (PAT). ACCT and APAT are identical 1Hz timescales, but since the definitions of the origins of NTP, 1588/PTP, and Unix/POSIX timescales are stated in terms of TAI or UTC, ACCT and APAT are defined in terms of CCT and PAT to retain the distinction. Leap Seconds are renamed Earth Corrections. Earth Corrections behave identically to Leap Seconds after 1972-01-01T00:00:00Z (UTC) = 1972-01-01 00:00:10 (TAI), or 1972-01-01T00:00:00Z (CCT) = 1972-01-01 00:00:10 (PAT). 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). The legend, table, and diagram below summarize the design of the CCT timescales. CCT - Common Calendar Time (Coordinated Universal Time (UTC) after 1972-01-01T00:00:00Z(UTC)) ACCT - Anterior Common Calendar Time (1Hz scale before 1972-01-01T00:00:00Z(CCT)) PAT - Proper Atomic Time (International Atomic Time (TAI) after 1972-01-01 00:00:10(TAI)) APAT - Anterior Proper Atomic Time (1Hz scale before 1972-01-01 00:00:10(PAT)) EC - Earth Correction (formerly Leap Seconds) Origin | CCT1972| Coincides | ACCT| Earth | APAT Name| Seconds| with | |Correction| | Offset | Origin of | CCT| | PAT ACCT1900| -2272060800 | NTP| 1900-01-01T00:00:00Z | 10 | 1900-01-01 00:00:10 APAI1958| -441763210 | TAI| 1957-12-31T23:59:50Z | 10 | 1958-01-01 00:00:00 APAT1970| -63072010 | 1588/PTP | 1969-12-31T23:59:50Z | 10 | 1970-01-01 00:00:00 ACCT1970| -63072000 | Unix-POSIX | 1970-01-01T00:00:00Z | 10 | 1970-01-01 00:00:10 APAT1972| -10 | TAI1972-10 | 1971-12-31T23:59:50Z | 10 | 1972-01-01 00:00:00 PAT1972 | 0 | TAI1972| 1972-01-01T00:00:00Z | 10 | 1972-01-01 00:00:10 CCT1972 | 0 | UTC1972| 1972-01-01T00:00:00Z | 10 | 1972-01-01 00:00:10 CCT1972_7_1 | +15724800 | First Leap | 1972-07-01T00:00:00Z | 11 | 1972-07-01 00:00:11 CCT1980_1_6 | +252892800 | GPS Epoch | 1980-01-06T00:00:00Z | 19 | 1980-01-06 00:00:19 TAI APAT1958 1958-01-01 00:00:00 | 1588/PTP | APAT1970 | 1970-01-01 00:00:00 | |PAT1972 | |1972-01-01 00:00:10 TAI | | | APAT - - - -|- - - - -|- - - - - - - - - | PAT -441763210 -63072010 0 | EC 10
Re: [LEAPSECS] Common Calendar Time (CCT) - timescale design -Brooks Harris
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
Re: [LEAPSECS] Common Calendar Time (CCT) - timescale design -Brooks Harris
On Sun 2014-01-19T23:53:44 +, Zefram hath writ: 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. Yes, well-defined, but not defined in a contemporary sense that any such time stamps could have existed. Anything with that stamp was reconstructed ex post facto. The CCDS meeting which produced the definition for TAI was held 1970-06-18/19. After that got to the CIPM that became known as Recommendation S 2 (CCDS, 1970), in CIPM, 1970 The CGPM meeting which authorized the existence of TAI was opened 1971-10-04 in Resolutions 1 and 2. This is a perennial problem in metrology of things that progress. If a precise definition is desired for a coordinate origin then that origin must be expressed in measures of the current conventional value with current technologies. The past of POSIX time stamps can never be disambiguated without argument. If it becomes possible to choose a new time scale with which everyone can live then the POSIX standard will have to specify a new conventional date at which time_t has a new conventional count of seconds. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Common Calendar Time (CCT) - timescale design -Brooks Harris
On 2014-01-19 03:53 PM, Zefram wrote: Your definitions are generally poor. There is much that you omit or make horrendously unclear. There really aren't any definitions yet. Its an informal email. I'd hoped I could make a little progress without completing the entire document. Maybe not. 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. That's not fair. I've got one international standard under my belt as primary author that retains whole swaths unchanged from my strawman proposal. I've contributed significant sections and modifications to standards text for over 15 years. I've got a 30-odd page document draft of this proposal on my desktop. I've got an exploratory c/c++ implementation of it running which does what's intended and which interacts with POSIX, Windows and SNTP in ways I expect. Both the implementation and any formal description of it are particularly hard problems given the long and tortured history, the myriad of objectives, and entrenched attitudes. I appreciate your constructive input. Thanks. -Brooks 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 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
