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

[Brooks Harris]

On 2014-01-17 05:08 PM, Zefram wrote:

> Brooks Harris wrote:

>> The idea behind "CCT" is to better define "civil time".

> That seems only vaguely related to your more clearly stated objectives

> of proleptic versions of TAI and modern UTC.  It's too late to better

> define pre-1972 civil time, and proleptic extension of UTC doesn't affect

> current civil time at all.


No intention of "better define pre-1972 civil time". As per other 
emails, the intention is to better define time-keeping after 1972. The 
purpose of the "proleptic UTC" (and we need a better name) is to provide 
a scale where the NTP, POSIX, and 1588/PTP origins can be unambiguously 
defined in relation to 1972-01-01T00:00:00Z. Its an entirely artificial 
scale for computational convenience.


>> The mapping between TT and TAI is known,

> You're glossing over a lot here.  I'm not sure what you're trying to imply

> by this statement.  It sounds rather as though you're still conflating

> these two classes of time scale.


Maybe. But as I understand it the timescales we are interested in for 
practical implementation are TAI and UTC. The whole purpose of TAI is a 
"realization" of TT, right? TAI shields us (I mean us normal computer 
people, not astronomers or cosmologists) from the details of how TAI is 
maintained (and hats-off to the folks that do that!). And UTC operates 
with respect to TAI. Thats what we have to go on, I think.


>> 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.

> Those are totally unimportant, as applications of proleptic UTC.  The NTP

> epoch, and to some extent the Unix epoch, is not really a specific point

> in time, it's merely a notional timestamp.



>   Both NTP and POSIX time

> values are simple mathematical transforms of broken-down UTC timestamps,

> not counts of seconds.

I don't think so. Both are indeed counts of Seconds, and both have a 
relationship to UTC time.

The NTP "prime epoch" is 2,272,060,800 Seconds before 
1972-01-01T00:00:00Z. Thats a clear statement of its relation to UTC. 
The timestamps are Seconds and fractions of Seconds - its a Seconds counter.

time_t of POSIX is "Seconds since the Epoch". Thus its primary counter 
is a count of Seconds and stated to be "UTC", although "the Epoch" is 
vaguely defined.


>   You can describe the NTP epoch as "1900-01-01

> 00:00:00 UTC", but all that means is that the mathematical transform maps

> between that timestamp and time value 0.

"time value 0" is 2,272,060,800 Seconds before 1972-01-01T00:00:00Z.

> That timestamp doesn't have to

> be meaningful as a time (as indeed it isn't), because the only NTP time

> values that actually get processed are much higher values corresponding

> to contemporary times, for which UTC timestamps are meaningful.

Are you saying there is no *accurate* time before 1972-01-01T00:00:00Z? 
Of course. But those "epochs" have a known relation to UTC - they are 
computational contrivances, but they are significant for implementation.

> There is

> no value in associating the NTP epoch with a specific instant in time.


It *is* associated with a "specific instant in time" - its is 
2,272,060,800 Seconds before 1972-01-01T00:00:00Z.

I must be misunderstanding what you're getting at here. I can't believe 
our understanding of this is so completely different.



> >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.

> POSIX time is a subtype of Unix time.  The term "Unix time" refers to

> how time has been handled in the Unix tradition as a whole.  "POSIX

> time" refers specifically to the definition in the POSIX.1 standard.

> POSIX refers to UTC by name; prior to POSIX the equivalent reference in

> the documentation was to GMT.

>

>> A central problem is the definition of the POSIX "The Epoch".

> Though the POSIX definition of the epoch has a problem by referring

> to UTC for a time prior to the modern form of UTC, as with the NTP

> epoch this is of no importance at all.  It has absolutely no impact on

> the interpretation of timestamps resulting from the POSIX definition

> of time_t.  Unlike NTP, there probably are Unix timestamps that old,

> but since they're firmly pre-POSIX their interpretation must be governed

> by the pre-POSIX traditions, and of course sub-second accuracy is not

> expected for that era.

>

> Also, if you define something that amounts to a proleptic UTC, that

> doesn't in itself affect the interpretation of NTP or Unix time values.

> You are not changing UTC, nor discovering previously-unknown historical

> behaviour of UTC.  You are defining something new.


Yes, its new. Well, actually, NTP already defined something like it, but 
here I'm trying to make it also encompass POSIX "the Epoch" and 
1588/PTP's "epoch" - "1970-01-01T00:00:00Z".


> It would only affect

> NTP if the NTP protocol were revised to explicitly reference your new

> time scale in place of UTC.  That would be rather pointless, since, as

> discussed above, NTP isn't used to process such historical timestamps.

No attempt here to "process such historical timestamps". Only to tie 
NTP, POSIX, and 1588/PTP to 1972-01-01T00:00:00Z for computational 
convenience and explicitly define the relation, or Seconds offset, 
between them.


> A corresponding POSIX redefinition would have slightly more applicability,

> as time_t does get used for historical purposes, but it still wouldn't

> affect time values actually recorded in 1970.

Again, no intention of addressing "historical purposes". I'm trying to 
do away it.


>

> Defining a proleptic extension of UTC is a valid and interesting exercise,

> and has potential applications, but not the ones you seem to expect.

Again, its not really "proleptic UTC" - that's probably the wrong name.

Yes, defining a *true* proleptic extension of UTC would be a valid and 
interesting exercise, but thats not my intention with "CCT".

-Brooks


> You're also mixing concerns that are better kept separate.  Proleptic TAI,

> proleptic UTC, and local time zones are all more or less separate issues.




>

> -zefram

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>

>