time.h design issues
D. J. Bernstein
djb at cr.yp.to
Sat Aug 28 00:12:07 UTC 1999
Paul Eggert writes:
I don't understand what problems you're trying to solve here.
Time libraries should be designed to support the features that real
programs need. For example:
* Benchmarking tools need to measure differences in real time.
Consider the gettimeofday() function.
* Networking tools need to schedule events at moments in real time:
e.g., send this packet 0.2 seconds after that one. Consider the
select() and poll() functions.
* Clock programs need to know the current time in the local time
zone. Consider the time() and localtime() functions.
* Mail readers, given a list of civil times from various time zones,
need to sort the times into numerical order. Consider the mktime()
* Calendar programs need to know tomorrow's date, the number of days
until next month, etc.
Evidently there are four basic objects here:
* Calendar dates: year-month-day.
* Civil times: year-month-day, hour-minute-second, zone.
* Date intervals, expressed as a number of days.
* Time intervals, expressed as a number of seconds.
Arithmetic on intervals is trivial. To support arithmetic on calendar
dates and civil times we can set epochs and provide a few fundamental
* Convert seconds-since-epoch to a civil time in the local time zone.
* Convert any civil time to seconds-since-epoch.
* Convert days-since-epoch to a calendar date.
* Convert a calendar date to days-since-epoch.
If the system keeps track of the current time as seconds-since-epoch
then we can convert it to civil time in the local time zone.
More information about the tz