Paul Hill wrote on 1999-08-28 02:30 UTC:
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:
Your examples where perfectly good, but you left out some of the real fun calendar calculations.
There are two very different types of date/time libraries here, and we have to be careful not to mix up the two: A) Base functionality access to resources that cannot be accessed at the moment in a portable way (mainly: TAI, UTC, leap second announcements, centrally administrated geographic time zone information, operational status of TAI/UTC reference, etc.). B) Ultracomfortable handling of any sort of time, whatsoever, including various calendar systems, financial algorithms, historic dates, astronomical and clerical algorithms, etc. I feel that A) deserves to be standardized, because it is part of the information infrastructure that an operating system has to provide. Whether it becomes part of C, POSIX, or some other formal standard is more a political than a technical issue. The functionality of B) on the other hand can be implemented in a fully portable way in C already today. You have the base functionality of integer arithmetic, on top of which you can build whatever date and calendar classes you feel like. I do not think that there is a real need to standardize these at all, just like there is no real need to standardize interfaces to linear algebra packages. A single high-quality portable freeware implementation is all that is needed to keep us happy. Especially note, that there is no reason that A) and B) have to use the same data types. It is only necessary that B) understands the data types of A). 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, even though this will hardly ever be necessary in practice unless we make significant and amazing breakthroughs in physics. There are many good reasons, why a base mechanism should be built around fixed-point arithmetic (the clock's resolution doesn't change of time, so why shift a comma?), while a comfortable calendar algorithm system could be better build around floating point numbers, for instance (who needs nanosecond precision time back in 25000 B.C?). My and Paul's proposal very clearly restrict themselves to the scope of A), that is they want to provide in a portable way access to infrastructure information that is otherwise not accessible. These proposals want to replace gettimeofday() such that the kernel or time daemon in the OS provides a richer menue of information for the application to choose from, plus they want to provide sufficiently flexible read access to a timezone database. Dan's libtai on the other hand (as I understood it) targets more towards B), i.e. it sits on top of the existing gettimeofday() base mechanism, and it tries to make a best-effort conversion of what gettimeofday() provides (with all its inherent limitations, e.g. undefined behavious during leap seconds) into a format that is more suitable and easier to handle for certain types of applications, most notably those where leap seconds are undesired effects and that care more about accurate interval measurements than an accurate and reliable relationship to the civilian time notations. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>