In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In message <[EMAIL PROTECTED]>, Peter Bunclark writes:
:
: >I would have thought that part of the answer to the difficulty in
: >implementation and testing would be to use an open-source library of tried
: >and tested algorithms. I don't quite understand why software engineers
: >seem to feel the need to write new leap-second handling code every time
: >they invent a new gadget.
:
: The vast majority of software engineers do use standard code, they
: use their operating systems libraries, this makes them seemingly
: leap second compliant.
:
: "Seemingly" here covers that they are only compliant in all the
: seconds that are not leapseconds or seconds right before leap
: seconds.
:
: The POSIX definition makes it impossible to correctly handle leap
: seconds with any complying implementation of the standard, and
: therefore applications which needs to be *truly* leapsecond compliant,
: cannot use the standard libraries.
Not to mention devices that handle leap seconds almost, but not
entirely, correctly. Much of the fancy footwork that I've had to do
is because some devices are better than others at their pedantic
compliance. If one relies on just one detail that's gotten wrong,
then one's downstream data will be wrong. Knowing what one can trust
and not trust, as well as building in the cross checks is also very
device specific. This motorola receiver gets this datum wrong, but
that datum right, while this other motorola receiver gets it the other
way round. This other GPS receiver supplies data that sounds like it
should be the same as the reliable motorola data, but in fact is
something subtly different.
The problems generally aren't in the leap second ticking code (which
is in the kernel and has been proven correct through repeated
testing). The problems are in getting experience with the actual
details of how a specific device (and sometimes the specific firmware)
operates. The problems are in what optimizations one can make to
recover time faster from a cold start than waiting for the leap info
to arrive at some random time in the next 1/2 hour. The problems are
in what the power off behaviors of devices are. The problems can even
be in how one tests the leap seconds in a simulator because some
devices have a strong notion that time flows forward only and produce
bad data for a while when that notion is violated.
All these details are hard to enshrine in a write once, reuse forever
open source (or even closed source) library.
Warner
