time.h design issues
D. J. Bernstein
djb at cr.yp.to
Sat Aug 28 20:03:23 UTC 1999
libtai isn't an abstract ``improve the C time API'' thought experiment.
It's a collection of time routines that I'm using in several programs.
libtai started as a pair of fast routines to convert seconds-since-epoch
to RFC 822 year-month-day-hour-minute-second-gmtoff timestamps and back.
Typical time.h implementations used an absurdly slow binary search for
mktime(), frittered away several pages of memory per process, and didn't
have any sane way for mktime() to deal with gmtoff.
libtai grew when I started fixing Y2038 bugs. I'm not worried about
time_t, which will eventually be extended to 64 bits; I'm worried about
4-byte timestamps in inodes and tar files and other databases. So I
wrote some routines to manipulate a simple, portable 8-byte timestamp
format with 1-second precision, and a high-precision 16-byte extension.
The reason that I'm skeptical about the complicated vaporware proposals
is that libtai has already proven adequate for a variety of tasks:
* Synchronizing the local clock using SNTP.
* Recording precise timestamps in system logs.
* Scheduling a torrent of network events.
* Handling email timestamps. (See mess822 or the next qmail release.)
My clock ticks monotonically in real time from a particular epoch. I
don't need TIME_MONOTONIC and TIME_TAI and TIME_SYSTEM; they're all the
same thing. Nowhere is there any use of the fundamentally broken time
scales TIME_LOCAL and (deceptively named) TIME_UTC.
I'm not saying that libtai 0.60 is a complete replacement for time.h. In
particular, it doesn't generate civil times in zones other than UTC; if
you want to display a local clock then you have to call localtime().
Markus Kuhn writes:
> I am often puzzled to hear people expect, that the data format
> that comes out of the real-time clock interface has to accommodate for
> times back to the big bang,
You misunderstand. That's merely a side effect of changing time_t from
32 bits to 64 bits so that it handles dates in the foreseeable future.
---Dan
More information about the tz
mailing list