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