time.h design issues
Markus Kuhn
Markus.Kuhn at cl.cam.ac.uk
Sat Aug 28 08:55:55 UTC 1999
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/>
More information about the tz
mailing list