>>>>> "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.
Description: PGP signature