Poul-Henning Kamp wrote on 2006-01-19 11:59 UTC:
> 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.
Having just observed Linux kernel crashes caused by a "rubber second"
that was -1 (!) SI seconds long last New Year's eve, I believe you
overestimate quite a bit what the "precision specs set forth in the NTP
protocol" count out there in the real world today. I hope you appreciate
that the brutal way in which some systems implement leap seconds
currently is *far* worse in any respect than UTC-SLS ever could be. If
your NTP server
- halts the kernel clock for 1 second, or
- steps it back by 1 second at midnight, or
- starts to oscillate wildly and finally loses synchronization and
resets everything after 17 minutes
(all these behaviours have been observed, see ongoing NANOG or
comp.protocols.time.ntp discussions) then *this* is the worst-case
scenario that your entire NTP-synched system must be prepared for.
UTC-SLS is infinitely more harmless than a negative step in time.
> 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.
Your choice of words occasionally leaves signs of diplomatic skill to be
desired. Anyway, to repeat what Appendix A of the spec says in more
detail:
I did play with this idea and discarded it, because having prime factors
other than 2 or 5 in the smoothing-interval length I leads to unpleasant
numbers when you explain the conversion between UTC and UTC-SLS by
example.
For instance, if we used I = 15 min = 900 s, then we get
UTC = 23:45:00.000000 => UTC-SLS = 23:45:00.000000
UTC = 23:45:01.000000 => UTC-SLS = 23:45:01.000000
UTC = 23:45:02.000000 => UTC-SLS = 23:45:01.998889
UTC = 23:45:03.000000 => UTC-SLS = 23:45:02.997778
...
UTC = 23:59:58.000000 => UTC-SLS = 23:59:57.003333
UTC = 23:59:59.000000 => UTC-SLS = 23:59:58.002222
UTC = 23:59:60.000000 => UTC-SLS = 23:59:59.001111
UTC = 00:00:00.000000 => UTC-SLS = 00:00:00.000000
I find that having infinite decimal fractions showing up obscures just
the real simplicity of the conversion much more. It get's much worse
when you do UTC-SLS -> UTC conversion examples. That's why I prefer I =
1000 s over I = 900 s or I = 1800 s. Blame the ancient incompatibility
between Indo-Arabic and Babylonian number systems if you want.
And I do not like I = 60 min simply because
a) see above
b) this cannot be implemented by DCF77/HBG/etc. receivers, which get
only 59 minutes advance warning.
c) it could shift by 0.5 seconds deadlines on the full hour in
time zones that differ from UTC by an odd multiple of 30 min.
> 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 my initial assertion *was* right then after all ...
[Outline proposal deleted]
> 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/
About 8 years ago, when I was still young and naive as far as the real
world is concerned (you actually remind me a lot of these Sturm und
Drang days ...), I tried to convince people of a solution that I believe
goes somewhat into the direction of what you now have in mind. I had
enormous enthusiasm for comprehensive-kitchensink API approaches that
allowed me to write applications that can display 23:59:60. I still
agree that the POSIX time and time zone API can be improved
substantially. But I no longer think that any effort should be made
whatsoever to expose real-world applications to the time value 23:59:60.
I believe that UTC-SLS is not a kludge, but is a most sensible and
practical solution, *if* we accept the premise that civilian time
remains tied to UT1.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Thu Jan 19 2006 - 10:07:57 PST