time.h design issues

Paul Hill phill at myriad.com
Sat Aug 28 03:38:12 UTC 1999

Scott Harrington wrote:
> The calendar arithmetic issues Paul Hill brought up are another story
> altogether.
> Whether these should be part of a standard C library is debatable. 
> [...] Why expect so much of the OS vendor?

I'm not necessarily suggesting that the standard should include it.
I only mention it because D.J. Bernstein seemed to over simplify the 
list of what needs to be done with times in programs while starting to 
build a case for a simplified lib.

I would consider a library powerful enough if I could build the
three parts mentioned on top of the standard libraries without
repeating any of significant part of the data or calculations
already contained in the libs.

Those three parts are:
* [Relative] Time intervals, expressed as combinations of
unspecified [durations] of years, months, days, weeks, hours etc.

* Convert a calendar date or time to whole months, hours, weeks,
years, quarters, moons, pay periods :-) etc. since epoch with
or without considering TZ.

And alternately or in addition depending on your tastes, its 
related cousin:

* Convert a time to the another time that represents the beginning
of the period; i.e. beginning of year, month, week,
day etc. with or without considering TZ.

The second one seems like the key to other two, thus
a possible candidate for inclusion in a standard library.  I haven't
read all of the proposals, so this is not a criticism of any of them,
only a comment about what the areas of date/time could and might be.


More information about the tz mailing list