time.h critique

Markus Kuhn Markus.Kuhn at cl.cam.ac.uk
Fri Oct 2 13:10:24 UTC 1998


Dave Flater wrote on 1998-09-21 18:57 UTC:
> > I have read your quite strong critique on the current C/POSIX time API in
> >
> >   http://www.universe.digex.net/~dave/files/xtide-1.6.2.tar.gz
> >
> > I have recently written a proposal to a modernized time.h in C 9X, which
> > you can find on
> >
> >   http://www.cl.cam.ac.uk/~mgk25/c-time/
> >
> > When you have some time to read it, I'd be very curious on what you
> > think about it and whether this would fulfill your needs if it became
> > part of the next C standard.
> 
> I applaud the explicit passing of time zones, the new formats for
> strfxtime, the tz_jump function, and of course the fix for the year 2038
> problem.  However, I find that there are still some problems in dealing
> elegantly with non-continuities.  The following changes would make me
> happier:
> 
>    * Replace the boolean is_dst field of struct_tm with an open-ended
>      counter compatible with the A/B convention used by strfxtime, but
>      retain the option of leaving it unspecified.
> 
>    * Let xtime_make return an array of zero to N translations of the
>      requested time instead of either 1 or error.  Then when the A/B is
>      unknown (as it usually is), the application can get a complete answer
>      the first time instead of having to fumble around when there are
>      discontinuities.
> 
>    * Extend xtime_breakup to use the new A/B field in struct tm.
> 
>    * While you're messing with struct tm you can retire some of the other
>      silly rules like doing years relative to 1900 and the zero-based
>      numbering of months.

I agree fully that your ideas are good suggestions. However:

For binary compatibility reasons, we cannot change the size of struct
tm. We would have to add a new struct tmx, and double all related
functions, which would give the API a quite clumsy appearance. My plan
was therefore not to "mess around" with struct tm in any way that might
break existing applications. I do not think we gain too much by fixing
struct tm: It is hard to imagine that in any time zone a time will
repeat itself more than once. Therefore I think it is a reasonable
convention that xtime_make interprets tm_isdst as positive for the first
interval, zero for the second interval, negative as a reason for
signalling an error IF the specified time is ambiguous. If the specified
time was not ambiguous in the first place, tm_isdst should be ignored.

Surely there are more elegant ways to resolve these ambiguities, but
instead of trying to improve struct tm, I think it is much better to
make struct tm mostly irrelevant by giving strfxtime direct access to
all the available information in the struct xtime and timezone_t objects
directly.

> Other things that are not "broken" but that you might want to do:
> 
>    * Add an explicit interval type, an extended difftime function that
>      takes two xtimes and returns an interval, and the other obvious
>      operations.  I defined a bunch of operations over timestamps and
>      intervals in C++ for XTide 2.0 but for C you probably want to
>      keep it simple.

These are indeed rather simple to add, but what would be their semantics
in the presence of leap seconds?

>    * Conversions to and from Julian dates as double precision floating
>      point numbers would be nice and easy to do.

Yes, but this is a single-line function that everyone who needs it can
easily add himself. We can add conversions between TIME_UTC and JD or
MJD as example notes to the standard, but I would not want to create an
inflation of time scales in the basic library API. This sounds more like
a function for calendar and astronomy toolkits and not for something a
basic time access interface should be concerned with. It is also not
clear, what to do in the context of a leap second with the decimal
fractions of the day.

> Finally, we get down to the real bloat features and things that are out of
> scope:
> 
>    * I stand by my assertion that the Posix approach to tzstrings is the
>      Wrong Thing, and that the Right Thing would be to standardize the
>      tzstrings and functionality of Olson's zoneinfo database.

Agreed, and many workstation operating systems will hopefully implement
it at this level. But for tiny embedded controller applications we must
also allow the entire timezone package to be unimeplemented such that
only UTC or monotonic time are available. A requirement for an
Olson-like appraoch to implement timezone_t would be more appropriate
for a standard like POSIX than for a programming language standard with
a much wider scope. For tiny embedded environments (smartcards, etc.)
tz_prep should certainly be allowed to always fail.

>    * You might want to specify an optional function to map a latitude,
>      longitude, and xtime to the relevant tzstring for that location at
>      that point in history.  Probably nobody will ever implement this, but
>      if they do, it would be helpful to have a standard interface to it.

Well, we are getting far outside of the scope of a general purpose
programming language API here. May be, one day we get a nice
distributedly administrated database for universal Internet access to
up-to-date timezone information (in fact I have some long-term plans
along this line), and the access API to this could certainly provide
such a functionality such that your GPS-integrated car radio will
automatically reset the clock when you cross a border, but let's leave
this project until we have fixed the much more fundamental things.

Thanks a lot for your comments. I hope you don't mind that I Cc-ed this
on the Olson mailing list where xtide has been quoted before as an
example application.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>




More information about the tz mailing list