>>>>> "ab" == Alan Barrett <apb%cequrux.com@localhost> writes:
ab> I would have recommended that time_t should count seconds
ab> "correctly" without ignoring leap seconds
If we have one file modified on 2005-12-31-23:59:60 and another on
2005-12-31-23:59:59, there's no way to tell which is newer because the
filesystem is POSIX.
This sort of thing can fuck up digital video recorders. If the
software's brittle you may lose more than one second, and won't know
about the bug for years.
ab> applications or protocols that need to accurately represent
ab> future dates should use a representation with explicit
ab> year/month/day/etc components instead of time_t.
depending on what they want. Most things casually referring to the
future will in fact intend ``three hours from now,'' because they'll
be interval timers or ticket expirys for distributed systems, so I
think you suggest the wrong default choice.
But part of what a standard should do is help programmers become
well-informed enough to write what they intend. Before they read the
standard they're often ignorant even of their own intention. The
timer API mostly does this, but it's spread out:
CLOCK_MONOTONIC in clock_gettime, timer_create --
you cannot make interval timers from the wall clock because
sometimes people set this clock. (unless the software is spread
over several kernels and then you just have to hope they don't)
timer_getoverrun and the it_interval field in timer_settime --
you need to account for the latency of delivering expiry signals,
and also the latency of resetting timers, if your expectation is
to get, for example, exactly 24 timer-expirys per second.
not discussed very well --
the API allows setting intervals short enough, or precise enough,
to expose the underlying clock's limitations in jitter and
resolution
so, I think it's pretty good, though I guess it's like the third or
fourth try at that interface, and the documentation's disorganized and
doesn't reference the other superior and inferior timer interfaces,
and it's still not finished for short intervals so we have video
players timing themselves by watching sound packets disappear. but
pretty good.
The time_t standard fails here because the programmer is ready to use
the API before he's learned enough of our shared experience to make a
correct implementation. That's why it's proper to regard what POSIX
did here as lazy, meat-headed and embarassing.
I'm not saying the standard should whip quality out of poor
programmers. The timer standard didn't rescue Quagga. But at least
the standard ought to be written presuming a good programmer will read
it. Here they intentionally concealed programming problems they knew
existed, so now we're having this ugly conversation again because they
failed in their responsibility to (a) settle arguments, (b) educate.
Next time I don't want to pay their airfare---we can just copy the
microsoft foundation classes like gnome. or better yet, shit in a
bucket, fill it with water, and call it soap.
Attachment:
pgpegqsh_ExYP.pgp
Description: PGP signature