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