In message [EMAIL PROTECTED], Neal McBurnett writes:
On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote:
Assign different timescales very different
numeric epochs:
TAI:1972-01-01 00:00:00 UTC
For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together.
I chose the time when TAI became constant rate so that
all the rubber seconds are confined to negative values.
UTC:MJD's epoch.
That would be midnight in Greenwich of 1858-11-17. I don't see the
connection, and picking a time for which we don't know UT1 pretty
accurately and authoritatively will cause all kinds of arguments.
Well, any number will do, as long as the epoch is unique (also
with respect to time_t.
UT1:Flamsteads birthday ?
Cute. 1646-08-19
NTP:defined in RFC1305
== 1900-01-01
It's all magic numbers and as such they don't have to give any
meaning. We could just pull out a random number for each and
define that as the value of the timescale at some particular
well defined point in time, so it could be something like:
at 2006-03-01 00:00:00 UTC the timescales will have
the following values:
TAI:N1
UTC:N2
UT1:N3
etc. Given that all the timescales count in SI seconds, that
would leave a bit of math for people to build the conversion
tables, but that could be a task to be done only once.
I like giving magic numbers som kind of meaning though, if
nothing else to honour birthdays of people who deserve it.
Small platform implementations can use a smaller width,
for instance 64 bits split 48/16 and easily transform
to standard format by zero extension.
That would work for 9 million years or so.
Plenty, but the point is that bigger computers are multiple of
32 or these days 64 bits, so chosing 48 bits is just wasted
space and trouble on those.
Different epochs will make it painfully obvious when people
mix but don't match timescales in low quality implementations.
Now we just need a name for the proposal
I _really_ don't care what it's called, as long as it's defined correctly.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
