Brooks Harris wrote: > We're stuck with a giant legacy of 86400-second-day based systems, from > the operating systems to applications that rely on them, from SQL to > banking systems, from Excel to email. These systems must continue to > operate as expected, even if they're all inaccurate with respect to UTC > and/or ambiguous with respect to local time representations. >[...] > The existing systems are not going to be replaced; they all need to be > supported while defining a more uniform and UTC-accurate set of > procedures that may be used in parallel with, beside, on top of, or in > conjunction with, existing systems. If we keep arguing about what UTC > and POSIX are or are not because we don't like one or the other I don't > see how we get very far.
It seems to me we're stuck between the rock of Posix time_t that simply doesn't handle leap seconds, and the hard place of UTC that still has them. And it seems to me it's an untenable situation. (I'm summarizing; I'm sure readers of this list understand all this at least as well as I do.) We've got all sorts of wonderful mechanisms (NTP et al.) that keep all our computers synchronized to within milliseconds of each other, but then every 18 months or so some minuscule version of hell breaks loose, when practically every computer on earth ends up jumping a whole second, or repeating a whole second, because there's just no place in the time scale for the leap second. It's a mess; it's just about like jamming a 13th egg into a one-dozen carton. It seems to me we have two choices: handle leap seconds considerably better, or abandon them altogether. If we try to handle them better, two conclusions seem inescapable: 1. Posix-compatible time_t values will need to be smeared, spreading the leap second out more gradually, to eliminate sudden, unseemly jumps. 2. There needs to be a well-defined way to deliver true, non-smeared, leapsecond-aware UTC time to code that needs it. Putting these together, I conclude that any smearing for #1 needs to be done in the OS kernel, just before delivering leapsecond- unaware Posix-compatible time_t values. Doing the smearing anywhere upstream (as, for example, Google is doing it) precludes #2. As a proof of concept, I'm working on a set of Linux kernel mods to do both #1 and #2. I had hoped to have them ready for interested people to experiment with this Saturday, but unfortunately I'm not going to make it. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
