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@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
