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/>
On Fri, 2 Oct 1998, Markus Kuhn wrote:
Dave Flater wrote on 1998-09-21 18:57 UTC:
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?
Taking a difference between two times, or adding one to a time, would need a parameter to give the clock type; if this is TIME_UTC and the implementation cannot determine whether there was a leap second in the relevant interval an error would need to be signalled. Note that a basic design principle is (should be) that leap seconds should not need to feature directly in code using the library: programs should need only be careful to use the correct clock types (which for time differences will often be TIME_MONOTONIC) and degrade gracefully on systems which have no leap second table or no time synchronisation. -- Joseph S. Myers jsm28@cam.ac.uk
Markus, Thank you for your response, which I comment on below.
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.
That will suffice as long as this conventional behavior is mandated in the spec, very clearly, for xtime_make. Last time I checked, subclause 4.12.2.3 of the Rationale of the C standard (1989) let mktime do pretty much anything when confronted by ambiguous input, which made it impossible for an application to sort out the discontinuities in any reasonable, portable manner. Given reliable behavior as you described above, my desired function that returns 0 to 2 translations for a struct tm can be implemented in a few lines of code, with a few calls to xtime_make.
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.
Granted for strfxtime, but struct tm is needed for xtime_make which will never be irrelevant.
* 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?
Now that I read the leap seconds stuff more carefully, I guess you need to pass the clock_type as well to disambiguate that.
Yes, but this is a single-line function that everyone who needs it can easily add himself.
Granted, the remainder of my suggestions were out of scope for your current efforts on the C language pe se.
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.
If there are any POSIX folks listening, I urge them to pursue it. Regards, DWF
Markus Kuhn writes:
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.
In case you haven't noticed, the calendar plays a prominent role in struct tm and in the output of asctime(). If you want to convert civil times to time_t, for example, you can start by converting the calendar dates to MJD. libtai is structured this way.
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),
Why should we take your plans seriously? You claim that you can't even figure out how to distribute a few bits of centrally managed information per year to keep leap-second tables up to date. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html
] Markus Kuhn writes: ] > 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), D. J. Bernstein wrote: ] Why should we take your plans seriously? You claim that you can't even ] figure out how to distribute a few bits of centrally managed information ] per year to keep leap-second tables up to date. It's not just a question of how technically easy it might be, it's also important how many people care about the information being up-to-date. __________________________________________________________________________ David Keegel <djk@cyber.com.au> URL: http://www.cyber.com.au/users/djk/ Cybersource P/L: Unix Systems Administration and TCP/IP network management
participants (5)
-
D. J. Bernstein -
Dave Flater -
David Keegel -
Joseph S. Myers -
Markus Kuhn