In message <[EMAIL PROTECTED]>, 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 [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.
