In message <E1EzeCF-0007Wc-00_at_mta1.cl.cam.ac.uk>, Markus Kuhn writes:
>> Now, please show some backbone and help solve the problem rather
>> than add to the general kludgyness of computers.
>
>Been there, done that:
>
> http://www.cl.cam.ac.uk/~mgk25/time/c/
I remember looking at your proposal before and it suffers from a lot
of problems.
For instance it is pseudo-decimal while all contemporary computers
are binary. This costs a fortune in performance and creates more
coding mistakes than you can count.
It doesn't have enough resolution for any of the people involved
in serious timekeeping (NIST, BIPM, Timing.com etc)
It is a two-part representation, which means that you face the silly
problem that the C language doesn't give you access to the carry
bit, but I guess that is really obscured by the use of pseudo-decimal.
It also to some extent confuses representation and presentation
which are two very different things.
So while well intentioned, you simply didn't go far enough.
My proposal tries to lay the groundwork for handling the entire
problem way into the future, by extending the range both upwards
and downwards and supports multiple timescales with enough room
for another 250 accidents of standardization in that area.
>But I no longer think that any effort should be made
>whatsoever to expose real-world applications to the time value 23:59:60.
That is not for us to decide really. (And my proposal doesn't address
it btw, I'm only talking about the representation, not the presentation.)
If the leap-seconds are here to stay, and unless heavy duty political
power is brought to the issue by USA, that seems to be the case,
we will have to get used to 23:59:60.
And unless we handle it correctly, we will not be able to certify
POSIX systems in a lot of critical applications in the future.
Provided we define a convenient and sensible API for handling date
& time, 23:59:60 will not give people any more problems than any
other time of the day, because it will be entirely handled by the
library functions for time&date conversions.
Poul-Henning
PS: And this should not in any way be taken as a surrender on
my part, I still think leapseconds are wrong in every way
one can imagine.
--
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 - 11:03:59 PST