time.h design issues

[D. J. Bernstein]

Paul Eggert writes:
> http://www.twinsun.com/tz/timeapi.html

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()
     function.

   * 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
conversions:

   * 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.

---Dan