October 1998 - tz - lists.iana.org

Re: time.h critique
by Markus Kuhn Oct. 3, 1998

Oct. 3, 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/>

5 4

Re: (SC22WG14.6158) (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Canaglobe International Inc. Oct. 2, 1998

Oct. 2, 1998

The dilema noted by Clive Featherstone of a completely satisfactory technical solution versus layering on a still-not-staisfactory solution is, unfortunately, increasingly common in many standardization area particluarly those where there is a substantial sunk investment and user base in legacy systems. I would propose that one approaches the problem by (1) working on the development of a "completely satisfactory technical solution" for ALL the required functionalities and then, and in the context of (1) (2) develop interim solutions, migration strategies/paths, etc. generally as well as required for particular user bases (e.g. the MS-DOS) community In short separate (a) the totality of the needed/desirable from the (b) immediately do-able, need to recognize the reality of sunk investments. This having been recognized, mapped out and accepted, the only remaining contentious question then becomes one of time lines (pardon the pun). Trust that this is of some use - Jake Knoppers

1 0

Comments from David R Tribble on ISO C 9X time proposal
by Markus Kuhn Oct. 2, 1998

Oct. 2, 1998

Here are a number of good comments on the modernized <time.h> from an author of a related proposal, which I'd like to share with those of you interested in this project. ------- Forwarded Message Date: Tue, 22 Sep 1998 15:11:31 -0500 To: Markus Kuhn <markus.kuhn(a)cl.cam.ac.uk> From: David R Tribble <david.tribble(a)dallas.beasys.com> Subject: new time.h comments I have some comments on your new <time.h> proposal. Some of these ideas came from my original proposal concerning an extended-precision time type (which I have abandoned for the time being; the text is still available at http://www.flash.net/~dtribble/text/c0xtime.htm if you're interested). 1. I would prefer that the macro names begin with an '_' in order to keep them out of the user's identifier name space. Thus, you would have names like '_TIME_UTC', '_TIME_TAI', etc. 2. It would be nice to have the concept of an 'unknown' or 'unspecified' time. Such a value would indicate a time value that is not (yet) known or a time value that has not (yet) been set to a valid time. This could be defined as a special constant named '_TIME_UNKNOWN'. Arithmetically, this value would compare less than all other valid time values. 3. Similarly, it would be nice to have the concept of a 'never' time, i.e., a time that has not yet occurred or a point in time that will never be reached. This could also be considered as something akin to a 'maximum' time value. This could be defined as a special constant named '_TIME_NEVER'. Arithmetically, this value would compare greater than all other valid time values. 4. You have defined the ability to determine the resolution of the time type, but there is no way to determine the valid range that time values span. This could be done by defining the macros '_TIME_MIN_YEAR' and '_TIME_MAX_YEAR' which specify, respectively, the earliest year containing Jan 1 and the latest year containing Dec 31, that are representable by the time type. 5. Of the 'TIME_XXX' macros defined, only the last three (TIME_LOCAL, TIME_SYNC, and TIME_RESOLUTION) need to be disjoint bitmask values; the remaining macro values can simply be distinct numeric values (such as 1, 2, 3, 4, etc.). (Personally, I don't like constants used for commands to include a zero value; zero to me means "undefined" or "unknown".) 6. The TIME_UTC epoch is defined as starting at 1970-01-01, but has no well-defined value until after 1972-01-01. Why not just define the epoch as beginning at 1972-01-01? 7. By the same token, the TIME_TAI epoch is defined as starting as 1970-01-01 but has no well-defined values until after 1972-01-01. Why not just start the epoch at 1972-01-01? 8. You need to be careful that, when describing the TIME_TAI epoch and times reckoned within that epoch, that you do not imply that such reckoning *requires* accuracy to external TAI time sources (i.e., make it clear that synchronization with outside time counters is purely optional.) Some people might misinterpret this as an implied requirement, and use it as justification to ignore your proposal. 9. The flaw with the TIME_TAI representation is that, even though single leap seconds are taken into account in the encoding, the difference between two TAI times does not properly account for the true number of leap seconds between them. Perhaps a function should exist for the sole purpose of deriving the difference between two (TAI) times which does take into account all intervening leap seconds, to wit: int diffxtime(struct xtime *diff, const struct xtime *a, const struct *xtime b); Fills in '*diff' with the difference between 'a' and 'b'. Returns i<0 if 'a' is before 'b', or i>0 if 'a' is after 'b', else 0. Perhaps an 'int clock_type' argument is needed, too. 10. The TIME_MONOTONIC epoch is defined as beginning at the last system reset. Some systems are not capable of discerning time this way, and can only reckon time from the start of the current process. Indeed, the standard clock() function is defined with this in mind. Perhaps the TIME_MONOTONIC epoch should be defined similarly. 11. TIME_PROCESS and TIME_THREAD fill a definite need, a la the times() call of POSIX. However, there is no way to ascertain the total elapsed CPU time for *child* processes. Perhaps a TIME_PROCESS_CHILDREN? 12. There ought to be a way to retrieve information for the local timezone. The definition of tz_prep() states that a null argument returns information about "some externally defined default timezone". A better definition would return information about "the local timezone, possibly determined from some external source (such as the program execution environment)". Alternatively, another function could be defined for the sole purpose of retrieving the local timezone information, such as: int tz_local(timezone_t *tz); 13. The calling convention to tz_prep() could be made better, to wit: int tz_prep(timezone_t *tz, const char *restrict tzstring); On success, the function shall set the contents of the object pointed to by 'tz' with the appropriate timezone information. This is better because tz_prep() does not then need to allocate any memory (it is allocated by the caller instead). This means that tz_free() is not needed. AFAIK, no standard library functions explicitly allocate memory, and the ISO committee has tried in the past to avoid inventing functions that do so. 14. The xtime_breakup() function ignores xtp->nsec, which is a shame. As I have suggested in other postings and in my proposal, it would be nice to have access to subsecond precision in the 'tm' structure, but this poses a problem with binary compatibility with existing code. What we are left with, then, is the need to access both the broken-down 'tm' structure and the original xtime value, so that we have access to the full time information. (On a tangent note, I don't like the name; perhaps something like xtime_split() or xtime_expand()?) 15. Similarly (as I have suggested previously), strftime() and strxftime() should contain a format specifier for fractional seconds (subseconds). Your proposal provides this ability. An alternative approach would be to add conversion specifiers for getting at the subseconds, such as: %q milliseconds (3 digits, not rounded) %Q microseconds (6 digits, not rounded) etc. (If conversion size specifiers are added, we would only need one specifier letter.) 16. In spite of your desire to obsolete the time_t type, we will still need a way of converting between xtime and time_t types, if for no other reason than for providing a smoother transition away from time_t. Without explicit conversion functions, the only alternative is to convert by first converting to struct 'tm' values, which seems unnecessarily wasteful. 17. I agree that the 'tmx' structure, with its tm_ext member, is an ill-conceived invention by the ISO committee. There ought to be a better way to allow for future extentions without the need for an extra allocation area. How this chunk is allocated, deallocated, and passed to other functions is never discussed in the draft. 18. You are slightly incorrect about Microsoft using a float type for time_t; they use a 32-bit signed binary integer identical to the POSIX time_t type. Apple's Rhapsody O/S, however, uses a 'double' for times and intervals. 19. Minor typos: 1.2.1, xtime_get(), "Returns": <If time != NULL then> should be <If xtp != NULL then>. 1.4.4, strfxtime(), "Description": <full stop> should be <period>; <decimal dot or decimal comma> should be <decimal-point period or comma>, see wording in [7.11.2.1 localeconv()] for consistency. 2, Rationale, "Lack of control over timezone": <proofed> should be <proved>. 2, Rationale, "POSIX and BSD predecessors": <problematic> should be <problem>. One final suggestion, pertaining to your choice of representation for the xtime type: You might want to consider implementing the xtime type as a 64-bit signed binary integer value instead of a structure. Either 'long long int' or 'int_least64_t' would be appropriate, with the value of a given time t is: t = (sec x 2 x 10^6) + usec + (Lsec x 10^6) where 'sec' is the number of seconds since the start of the epoch, 'usec' is the number of microseconds since that second, and 'Lsec' is 1 if a leap second is present, otherwise it is 0. This encoding seems to accomplish the same goals as your xtime structure, with the advantage that, since it is a simple arithmetic type, computations can be performed on it more efficiently. And it is smaller than the structure (64 bits wide instead of 96). These make it more amenable for directly storing it in binary data files and transmitting across networks. Even though it has less high bits, it is still capable of representing time to the nearest microsecond across a range of over 146,000 years (BC73000 to AD73000), which should be quite sufficient for most applications. The only real difference between this type and your xtime type is the resolution; I think that microsecond precision would be useful for most applications. (Of course, we could push the resolution up by a factor of ten, encoding 100 nsec ticks instead of usecs, which would reduce the range down to BC7300-AD7300, or BC4713-AD9900.) I hope these comments help. I, too, am quite serious about getting a useful and "correct" set of time/date functions into the new C9X standard. I am in the process of feeding my suggestion to Clive Feather, who has expressed an interest in collecting such comments and rewriting section 7.23 of the C9X draft. --------------------. +1-972-738-6125 Work ,-. C++: the PL/1 of David R. Tribble \ ,---------------------' \ the 90s http://www.beasys.com `-' +1-972-738-6111 Fax `------------------- dtribble(a)technologist.com http://www.flash.net/~dtribble Support the anti-Spam amendment, join at http://www.cauce.org/ ------- End of Forwarded Message

2 1

Re: (SC22WG14.6158) (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Clive D.W. Feather Oct. 2, 1998

Oct. 2, 1998

Douglas A. Gwyn (IST) said: > I think we need to poll the voting members to determine whether > anybody insists on having struct tmx in C9x. If not, since there > has been some formal objection to it, backing out the struct tmx > related changes seems like an appropriate way to respond to > (adverse) public comment. > > Personally I'd rather see a completely satisfactory technical > solution than layering on a still-not-satisfactory solution. > Since I doubt the former can be done within the C9x schedule, > leaving <time.h> pretty much the way it was in C89 seems proper. I'm not happy with <time.h> as it is, but I'm a lot unhappier with the C89 version, and I don't like the proposals that Marcus Kuhn is writing either (I need to talk to him face-to-face about this). I would object, and would ask the UK to object, to any proposal that removes the new functionality without a good replacement. I will try to write this up more clearly when I find the time, but it probably won't be in the next week. -- Clive D.W. Feather | Work: <clive(a)linx.org> | Tel: +44 1733 705000 Regulation Officer | or: <clive(a)demon.net> | or: +44 973 377646 London Internet Exchange | Home: <clive(a)davros.org> | Fax: +44 1733 353929 (on secondment from Demon Internet)

1 0

Re: Modernized <time.h> for ISO C 9X
by Markus Kuhn Oct. 2, 1998

Oct. 2, 1998

Marc Brett wrote on 1998-09-18 12:09 UTC: > There have been discussions here before to the effect that TAI is the > One True Time and all systems should be based around it. This neglects > the fact that most of the world runs to UTC not TAI, and that the > maintenance of the TAI-UTC offset on all machines is an impossible > expectation. Your proposal has an important merit in that TAI-UTC > tables are not strictly necessary. > > Good luck getting this through! Thanks for your comments. 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/>

1 0

tzcode1998h.tar.gz and tzdata1998i.tar.gz
by Olson, Arthur David (NCI) Oct. 1, 1998

Oct. 1, 1998

The files ftp://elsie.nci.nih.gov/pub/tzcode1998h.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1998h.tar.gz are now available. These incorporate the changes for Brazil, Chile, and Germany circulated on the time zone mailing list earlier this week; also included is support for use of "24:00" in the input files for the time zone compiler. --ado

1 0