In message <E1EzXeg-0008Cr-00_at_mta1.cl.cam.ac.uk>, Markus Kuhn writes:
>Poul-Henning Kamp wrote on 2006-01-19 09:46 UTC:
>> > http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt
>>
>> The serious timekeeping people gave up on rubberseconds in 1972 and
>> I will object with all that I can muster against reinventing them
>> to paste over a problem that has a multitude of correct solutions.
>
>Just for the record, am I right in assuming that your point is already
>fully addressed in the UTC-SLS FAQ at
>
> http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/#faqcrit
No it doesn't.
My objection is that you invent a new kind of seconds with new durations
instead of sticking with the SI second that we know and love.
Furthermore, you significantly loosen the precision specs set forth
in the NTP protocol.
And rather than have one focused moment where things can go wrong,
you have now streched that out over 1000 seconds.
1000 seconds is an incredible silly chosen number in an operational
context. At the very least make it 15, 30 or 60 minutes.
But mostly I object to it being a kludge rather than a solution.
By pasting over problems the way you propose, you are almost
guaranteed to prevent them from ever being resolved a right way.
(In this context either of fixing/extending POSIX or killing leap
seconds counts as "a right way" in my book.)
So rather than waste time and energy on something as badly thought
out as this, I would far rather we tried to define a time API for
POSIX to adopt that makes sense.
By make sense I mean:
o conforms to relevant international standards
ie: recognizes the defininition of leap seconds since
for all purposes and intents we're probably stuck with
the blasted things for another 20 years.
o is workable from a computer architecture point of view
no more pseudo-decimal timeval/timespec idiocy.
o Caters to the needs of relevant user communities.
Here's a strawman:
Use a 128 bit signed integer.
Assign the top 120 bits as one integer field with
resolution of 1/2^56 seconds.
Assign the bottom 8 bits to an enum containing the
timescale in question.
Assign different timescales very different
numeric epochs:
TAI: 1972-01-01 00:00:00 UTC
UTC: MJD's epoch.
UT1: Flamsteads birthday ?
NTP: defined in RFC1305
Define functions to convert from one timescale
to another and define ERANGE as a return value when
outside the functions ability to do so (ie: future
dates on UTC).
Define a compact ascii (no i18n!) representation for machine
readable use. (Ie: XML, protocols etc).
Very clearly spell out that any timezone adjustments
must be carried out-of-band to this field.
Assign the UTC timescale a identifier of zero.
Advantages:
Sufficient resolution to represent any likely physical
measurement or realizable frequency for the forseeable
future (13.8e-18 seconds resolution).
Extracting the whole second part can be done by accessing
only the top 64 bits (which are enough to contain all
of history and then some).
Conversion to/from NTP timestamps is trivial.
Conversion to time_t is a matter of addition and extraction
of the relevant 32 bits.
The binary format makes for fast and efficient arithmetic.
By assigning the UTC timescale an identifier of zero,
the majority of implementations can disrecard the
multiple timescale aspect in total.
Small platform implementations can use a smaller width,
for instance 64 bits split 48/16 and easily transform
to standard format by zero extension.
High quality implementations will check the bottom 8 bits
for identity and fail operations that mix but don't match
timescales.
Different epochs will make it painfully obvious when people
mix but don't match timescales in low quality implementations.
Now, please show some backbone and help solve the problem rather
than add to the general kludgyness of computers.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Thu Jan 19 2006 - 04:10:06 PST