On 8 April 2010 10:56, Glen Turner <g...@gdt.id.au> wrote: > On Wed, 2010-04-07 at 11:57 +1000, Jamie Wilkinson wrote: >> On 3 April 2010 12:51, Nick Andrew <n...@nick-andrew.net> wrote: >> > Pity that unix time_t ignores leap seconds :-) >> >> And the corollary that anyone using ntpd or other time synchronisation >> discipline now has a gettimeofday() that breaks the POSIX definition. > > The point of an operating system is to present a useful abstraction > of the hardware, including the time of day clock. An abstraction > which includes all the arcana of timekeeping isn't actually that > useful for most applications. time_t -- despite its shortcomings -- > is a fine abstraction, so much so that most operating systems designed > since have stolen this abstraction rather than use a structure of > Y/M/D H:M:S as done by pre-UNIX operating systems. > > If you do need to track the arcana then there are multiple abstractions > of increasing complexity, all of which are deficient for some users, all > of which are less and less useful to everyday applications. > > Dissing time_t because it is so simple is to miss the point. It is a > good abstraction because it is simple and the majority of the > applications which use it wouldn't know or care what to do with a leap > second.
The problem I've seen in the wild is that time_t looks good enough most of the time, but the arcana starts to matter in certain applications at fine resolutions, when it gets stepped during leapseconds (breaking monotonicity). People using gettimeofday to measure timing in their applications because it looks right get surprised when time goes backwards for a moment and their logs are wrong, programs crash, etc; when they really wanted to use clock_gettime(CLOCK_MONOTONIC, ...) instead but just didn't know it; the introduction of the article Daniel Pittman posted earlier (http://naggum.no/lugm-time.html) sums the problem up as the impedance mismatch between "the mess that we call time, and the preciseness of time as an orderly concept in science and a mess in the rest of human existence" As an aside, the point I was making before about the POSIX definition is that time_t is supposed to represent the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970; however every time a leap second occurs, that timescale is reset. It's neither a monotonic clock nor a representation of UTC, but it frequently gets confused for both (which isn't so bad, it looks like UTC for the most part until we need to count a 61st second, but there's out human calendaring bias appearing again). Anything that assumes monotonicity and stability in the calendar is at fault; but for a specific example around time_t, any library using gettimeofday to figure out what "now" is, and then offering to calculate time offsets at seconds resolution over intervals of years needs to be aware of that fact; no library I'm aware of does this. Nobody cares that they celebrated 1234567890 24 seconds too late. (Hopefully nobody cares about celebrating 1234567890? ;-) People tend not to care about that resolution at that interval; too much data, so what does it matter anyway? (Aside aside: the perl calendaring libraries do make an effort to do the right thing if you need to know the number of days between now and before the Gregorian calendar started, which is roughly the same concept on a coarser granularity of phase.) If time_t was defined as a representation of TAI instead of UTC, it'd be harder to get it wrong. They're a good match; one's just a counter and the other is a stable monotonic timescale. Of course then you'd need a presentation layer to convert TAI into your local human calendar, but that's pretty simple once the model and view are separated; TAI is very easy to define, the conversion from TAI to UTC is welldefined, measuring time intervals from pairs of TAI dates is simple arithmetic because of the guarantees of that timescale. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
