- tz - lists.iana.org

Re: Porting zoneinfo routines to Win32?
by guy＠netapp.com July 15, 1998

July 15, 1998

> Not that I know of... but I've considered it. The ideal situation would be > to take this database and put it under the Win32 APIs. Unfortunately, this > is not simple because the Win32 APIs don't understand that time zone rules > vary from year to year. Depends on the API. "FileTimeToSystemTime()" doesn't care, just as "localtime()" doesn't care, and "SystemTimeToFileTime()" doesn't care, just as "mktime()" doesn't care; however, "GetTimeZoneInformation()" *does* care - but, then, so does part of the SV time zone API - all you get from it is "timezone", "altzone", and "daylight". Basically, the fields of a "TIME_ZONE_INFORMATION" structure on Win32 correspond to SV variables roughly as: Bias (daylight? altzone : timezone) StandardName tzname[0] StandardDate not available StandardBias timezone DaylightName tzname[1] DaylightDate not available DaylightBias altzone "StandardDate" and "DaylightDate" are tricky, but you could probably set them to the rules for the most recent transitions, or for the next transitions, when "GetTimeZoneInformation()" is called. It might be some work to infer that a POSIX-style rule was in effect, letting you do a day-of-month version of "TIME_ZONE_INFORMATION"... ...but, if the Olson code is ever changed to handle times that don't expire in 2038, it *might* make sense to, instead of just recording transition dates/times, record things like from this date to that date, the rule is this POSIX-style rule; from the previous date to this date, the rule is this other POSIX-style rule; from the previous date to this date, the rule is that it changes on this date at this time; etc., as a compression scheme, so that you don't just store a set of transition times from Jan 1 1970 00:00:00 UTC to 2^63 seconds after that, or whatever. In effect, you'd store the "Rule" entries, rather than the results of running those rules repeatedly. With a scheme like that, coughing up POSIX-style rule information would be easier. It can still handle rules that change from year to year, but if the rules don't change every year, you can have a single entry cover multiple years.

2 1

Parsing Dates?
by Chris Sells July 13, 1998

July 13, 1998

Has anyone used the zoneinfo data to parse date strings into tm structures, e.g. "6/2/69 1:00pm CST" or "Jun 2 69 13:00 CST"? Chris Sells http://www.sellsbrothers.com

2 1

Porting zoneinfo routines to Win32?
by Chris Sells July 13, 1998

July 13, 1998

Has anyone ported zic or related zoneinfo routines to Win32? Chris Sells http://www.sellsbrothers.com

1 0

FW: Daylight saving
by Hawkins Linda July 2, 1998

July 2, 1998

>-----Original Message----- >From: Hawkins Linda >Sent: Friday, 3 July 1998 8:40 >To: 'tz_request(a)elsie.nci.nih.gov' >Subject: Daylight saving > >I am setting up astrological charts and require a list of years when daylight >saving was and was not implemented in NSW. Do you have a list of this >information and is it possible to receive it at my Email address? > >HawkinsL(a)chat1.epa.nsw.gov.au > >Thank you, > >Linda. >HawkinsL(a)chat1.epa.nsw.gov.au >

1 0

Daylights saving time help need
by Howard Fine June 28, 1998

June 28, 1998

I wonder if you can help me. I am trying to find a web site that lists when a country changes from summer to daylights saving time and back again. Any ideas? Thanks Howard Fine

1 0

Re: My Response to PC-US0010 (Eggert)
by Paul Eggert June 24, 1998

June 24, 1998

Date: Fri, 19 Jun 1998 17:23:06 +0100 From: "Clive D.W. Feather" <clive(a)on-the-train.demon.co.uk> What I did was wrote half the process - convert unnormalized time to a number of TAI seconds since some epoch. Rather than writing the other half and risking inconsistencies, it seemed better to simply express it as requiring the normalized time to produce the same result. The draft C9x spec in effect allows the implementation to consult an oracle to determine part of mkxtime's output, which means the draft actually specifies a relation between mkxtime's input and output. Since it's a relation, and not a function, there's not much point to writing the inverse. It's OK to require that the input members of the normalized time should remain unchanged when passed again to mktime/mkxtime; but it's not OK to also require that mktime return the same time_t value, or that non-input struct members (e.g. members not required by the standard, or tm_ext if that kludge is preserved) preserve their values. You've made me spot one gap in my logic. If you set tm_leapsecs to 0 before normalizing, the time is effectively TAI, while if you set it to _NO_LEAP_SECONDS it is effectively UTC. The output, however, is always UTC (unless there is no leap second database, in which case tm_leapsecs is set to _NO_LEAP_SECONDS). There's no trivial way to convert it to TAI, unless you know of an algorithm. Do we need a _USE_TAI value as well (indicating that the result should be TAI) ? I don't think the current draft's primitives are suited for conversion between UTC and TAI. If it were, then there would have to be an easy way to generate a broken-down TAI time from a time_t value. If it's important to support things like this, the primitives need to be rethought. But I suspect that the vast majority of users don't care about TAI, and that this sort of feature doesn't need to be in the standard. I believe that the <time.h> primitives need rethinking anyway. If we're going to reform mktime, for example, we should separate the original broken-down time from the broken-down time to be added, since that will remove some gotchas with the current approach. E.g. one month after Aug 31 ought to be Sep 30; but mktime yields Oct 1 because it can't distinguish ``add one month to Aug 31'' from ``add one day to Sep 30''. (This problem also resurfaces with leap seconds.) But more important, implementation experience, both on the part of implementers and users, is necessary before the standard is changed. It's unwise to add more <time.h> primitives without significant, public real-world experience.

1 0

draft C9x <time.h> (followup to Clive Feather's 18 Jun comments)
by Paul Eggert June 24, 1998

June 24, 1998

Date: Thu, 18 Jun 1998 17:32:40 +0100 From: "Clive D.W. Feather" <clive(a)on-the-train.demon.co.uk> This explains, I hope, why there are no reentrant versions of the functions in <time.h> - no-one expressed any desire to have them added (or if they did, they didn't do anything about it). It's fair to say that the C9x deliberations on <time.h> have not been publicized well outside the committee. The public C9x draft was the first I'd heard of it, and I try to follow time zone programming issues fairly closely. On this particular issue, there is considerable expertise outside the committee, and I hope that the committee will be open to careful criticisms by outside experts. There is a widely recognized need for ``reentrant'' versions of localtime, gmtime, etc. The need is so widely recognized that these functions are now in POSIX.1. It would be a shame for C9x to omit them -- there's nothing POSIX-specific about them. (I quoted ``reentrant'' above because the POSIX.1 functions aren't really reentrant if you are changing locales or time zones on the fly, but that's a larger subject and I presume that C9x won't be able to address it.) 7.16.1 para 3: Replacing tm_zone with tm_gmtoff (except that it ought to be called tm_utcoff) True, but (alas) the name `tm_gmtoff' is in common use, and it's consistent with the name `gmtime'. The tm_ext and tm_extlen members are not a kludge, but rather an anti- kludge! ... WG14 felt the adopted proposal was optimal. I'm afraid that the only opinions that I've seen (which are not from WG14) are that the tm_ext and tm_extlen members are a kludge. They don't reflect existing practice, and there's no precedent for them in other parts of the standard. They are an experiment invented by the committee, and it's quite likely that they won't work well in practice. Let me give an example problem that might arise with these new members. I assume that the implementation can allocate storage and assign its address to tm_ext; surely this is part of the point of tm_ext. Can it later free that storage? If so, then how can an application ever copy struct tmx values returned by the implementation, since their tm_ext members might be invalid? If not, then won't there be problems either with garbage collection or reused static storage? The storage allocation problem becomes worse if we have reentrant functions like localtime_r, since then the static storage solution is not even feasible and we are forced to deal with garbage collection issues. For this reason alone, tm_ext should go. You mentioned that the committee considered other possible approaches; what were they, and what objections did the committee have to them? Perhaps I can suggest improvements on them that would overcome the objections. 7.16.2.3 para 4: I don't understand your objection. The paragraph you cite means, in effect: the normalization process shall not alter a broken-down time that was generated by the normalization process But the standard also requires that the second call to mktime must return the same time_t value as the first call. That is what makes the requirement unrealistic. I see that I should have given more details about the problem (and I apologize for not being clearer in my earlier comments). Here's an example. Suppose I am in Sri Lanka, and invoke mktime on the equivalent of 1996-10-26 00:15:00 with tm_isdst==0. There are two distinct valid time_t values for this input, since Sri Lanka moved the clock back from 00:30 to 00:00 that day, permanently. There is no way to disambiguate these two time_t values with tm_isdst, since both times are standard time. Therefore, mktime should be entitled to return either time_t value. On examples like these, at least one mktime implementation (mine :-) can return different time_t values for the same input at different times during the execution of the program, since it uses a cache to improve performance. It's unreasonable for the standard to disallow this performance improvement. To normalize a struct tm, the implementation should do the equivalent of: - copy it to a struct tmx - set the additional fields and tm_isdst as described - normalize the result - copy the relevant fields back, except for tm_isdst which is just set to negative, zero, or positive as needed. But the last step of this process loses information, and the next invocation of mktime cannot reasonably be expected to intuit the lost information, as shown in the example above. 7.16.2.4 para 3: If tm_isdst is negative the zone information is not available, so the implementation should assume that "local time" has allowed for any DST in effect - in this case, 7.16.2.6 will set X2 to 0 in the algorithm. Thanks for the clarification. Perhaps you could add some text to the standard about this? 7.16.2.6 para 1: A negative tm_isdst, in both struct tm and struct tmx, means "unavailable". If POSIX.1 tries to give it a different meaning, POSIX.1 is broken. I wasn't referring to tm_isdst's value when I wrote ``negative daylight-saving time''; I was referring to a daylight-saving UTC offset that is less than the standard time UTC offset. I don't know that this has ever happened in practice (I've often heard rumors about it but none of them have ever checked out), but I'm leery that draft C9x disallows it, since POSIX.1 does allow it. Note that you never need to handle negative DST: take all the UTC offsets that the locale uses, and make the most negative the base time with all others being DST (in other words, replace negative "summer" time with positive "winter" time). But then tm_isdst can be nonzero even when daylight-saving time is not in effect. E.g. under your proposal, tm_isdst should be nonzero now in Sri Lanka (even though Sri Lanka does not now observe daylight-saving time), because Sri Lanka's UTC offset now (+0600) is greater than some UTC offset that it has had in the past (e.g. +0520). If this is what is really meant by struct tmx's tm_isdst member, then the member's name is misleading. Its name should be `tm_offset_from_most_negative_historical_gmtoff' or something like that. But frankly, I don't see how such a member's contents would be useful in practice, and I think users should avoid it entirely. 7.16.2.6 para 2: These limits were chosen to allow calculations to be done in longs without having to make excessive effort to avoid overflow. Even with no limits, a calculation shouldn't need excessive effort; it should need only a relatively small sanity check near the end. Your statement that you can't calculate today's date is wrong: tm_mday = time_t_now / 86400; tm_sec = time_t_now % 86400 My Unix host has leap second support, so that method doesn't work. However, I do understand your concern. I have no objection in principle to changing these limits.... Good; let's remove them. 7.16.2.6 para 3: (1) The algorithm assumes that "day" means 86400 seconds at all times This behavior is not reasonable in the presence of leap seconds. It's not what users will expect or want. If I'm writing an accounting application and ask for 1 day after midnight December 31, I don't want mktime to return December 31 merely because that day happens to have a leap second! Also, this behavior is not consistent with the other well-established properties of mktime. If I am at the start of a month and add 1 month, mktime returns the start of the next month, regardless of how many days are in the current month. Similarly, if I am at the start of a minute and add 1 minute, mktime should return the start of the next minute, regardless of how many seconds are in a minute. If you can construct an alternative algorithm I'll be please to look at it. There's no simple answer to this (which is why I don't think it ought to be in the standard). But since you asked, one way to do it is to normalize seconds-per-minute in a way similar to days-per-month. This is done in my free version of mktime. You can get a copy of a recent version from the latest GNU Emacs source code (<ftp:://ftp.gnu.org/pub/gnu/emacs-20.2.tar.gz>; see the file src/mktime.c) or from recent GNU/Linux C library sources. (2) S and D *are* determined - while they are implementation-defined in some circumstances (those when X1 and X2 are used), the implementation should only be able to pick one value for any given unambiguous input and environment. In order to choose X1 and X2, the implementation (in general) must know S and/or D. For example, how can the implementation choose the number of leap seconds to insert (X1) until it knows which day we're talking about (D)? So the definition looks circular to me. It sound like you're trying to break the circularity by saying that the implementation consults an oracle to choose X1 and X2. But in that case, more explanation is needed. For more about this please see (5) below. (3) It is C code (as should be clear from the typeface). There is no possibility of overflow if the limits of paragraph 2 are kept to, Yes there is. For example, suppose tm_hour == INT_MAX && INT_MAX == 32767. Then tm_hour*3600 overflows, even though tm_hour satisfies the limits of paragraph 2. This is just the first example I found; there are others. Also, if you remove the limits (as suggested by the comments to 7.16.2.6 para 2 above), then the overflow problem becomes worse if you assume the spec is written in C. If there is to be a detailed spec like this at all (which I'm not yet convinced of, considering its problems), I suspect that it will be much easier to write it using mathematical arithmetic than using C arithmetic; and if done well, it won't be any harder to implement. and there are no promotions or conversions happening as far as I can tell. The pseudocode doesn't declare the types of SS, M, Y, Z, D, or S. However, I presume that `int' won't suffice due to potential overflow problems like the one discussed above; and in that case, there will be promotions or conversions. (This problem is another argument for using mathematical notation instead of C here.) (5) I wrestled with this problem myself and failed to come up with a good answer.... can you find a better way of expressing it ? Sorry, I can't think of a simple change that will correct the problem. The only avenue that I can think of is that the section could be reformulated as a _constraint_ on S and D, not as a way of _determining_ S and D. That is, S and D would not be uniquely determined by the inputs. But this will require some real thought. If time is pressing, I suggest removing this section completely. If that's not acceptable, perhaps you can put in some vague English that expresses the intent. (6) Yes, an error does seem to have crept into the definition of D. The first line should read: D = Y * 365 + QUOT(Z,400) * 97 + REM(Z,400) / 4 - REM(Z,400) / 100 + This response doesn't address my criticism that the definition of D is unmotived. You wrote in response to (5) that ``Effectively D and S are the TAI date and time since some epoch,'' but you didn't say what the epoch is, nor did you say what ``effectively'' means. Please add comments so that it's absolutely clear what D and S are, so that other people can check your work. My comments on this section proposed a (slightly different) definition for D in which the epoch is 0000-03-01; this change doesn't need to be adopted as-is, but whatever definition that _is_ adopted ought to be explained. I currently have the impression that nobody other than yourself has ever completely understood the definition as it now stands. This is an unsatisfactory state of affairs. The rest of the expression is correct (including the Y at the start). Why is it Y and not Z? 7.16.3.5: The zonetime function is the struct tmx version of localtime and gmtime, but instead of offering only 2 choices of zone it offers any zone. No, zonetime doesn't offer _any_ time zone; it offers only local times that can be characterized by a single, invariant UTC offset. In practice, local times usually cannot be characterized this way, because they involve daylight-saving time, or historical changes to the underlying standard UTC offset, or both. For example, I can't use zonetime to determine the broken-down time for `*timer' in London's time zone, because London observes daylight-saving time (and also because London's standard UTC offset has not always been zero). This means that `zonetime' is of only limited use in practical applications. It hardly seems worth adding to the standard. 7.16.1 para 2: The limits of 14400 are correct. This allows you to adjust by up to 10 days (not 1 day) in an unnormalized time without risking accidentally using _LOCALTIME. Ideally _LOCALTIME would be something like INT_MAX or LONG_MIN. OK; but please add a footnote to this effect, as it's confusing otherwise. 7.16.2.6 para 3: The macros can't hit overflow with the limits of paragraph 2. Yes they can, because those limits are in terms of LONG_MAX, but sometimes the arguments of the macros are int, not long. (Also, as mentioned earlier, if the limits are removed, the macros can overflow even if int and long are the same size; but all this is irrelevant if we're using mathematical notation, not C.) Finally, I didn't see any response to my comment (quoted below) for section 7.16.3.6 paragraph 5; did I miss something? ``If this value is outside the normal range, the characters stored are unspecified.'' What is the ``normal range''? The range as output by localtime, the range of the Gregorian calendar, or the limits as specified in 7.16.2.6?

1 0

two responses by Clive Feather to my comments on draft C9x <time.h>
by Paul Eggert June 20, 1998

June 20, 1998

[forwarded with permission] ------- Start of forwarded message ------- Date: Thu, 18 Jun 1998 17:32:40 +0100 From: "Clive D.W. Feather" <clive(a)on-the-train.demon.co.uk> Subject: My Response to PC-US0010 (Eggert) ... Firstly, let me cover the history of these changes. Some years ago I and some friends identified a number of abiguities and discrepencies in <time.h>, which we described in various Defect Reports. Given the opportunity to make changes that C9X represented, I wrote a formal proposal to fix the problems I saw. After WG14 made some changes, this proposal was accepted. It was open to Paul, or anyone else, to write and submit a formal proposal for any problems he saw. This explains, I hope, why there are no reentrant versions of the functions in <time.h> - no- one expressed any desire to have them added (or if they did, they didn't do anything about it). 7.16.1 para 3: Replacing tm_zone with tm_gmtoff (except that it ought to be called tm_utcoff) that is measured in seconds: I don't have any objections to this. Appropriate other values need to be multiplied by 60. Um, the type needs to be changed to "long" to give it sufficient range. The tm_ext and tm_extlen members are not a kludge, but rather an anti- kludge ! The issue is not one of incomplete specifications, but rather of future-proofing. Suppose that C0X (the next revision after C9X) wishes to make a change to struct tmx. If it added extra fields to the structure, existing objects linked with a new library might access beyond the end of the object. It isn't sufficient to use the tm_version field for this, because a struct tmx with version 2 in the library might be copied to a struct tmx in the code which is only large enough for the version 1 fields. There are a number of ways to solve this problem (for example, you could add a tm_len field to the struct tmx, which is required to be set to the size of the struct tmx object as declared). WG14 felt the adopted proposal was optimal. 7.16.2.3 para 4: I don't understand your objection. The paragraph you cite means, in effect: the normalization process shall not alter a broken-down time that was generated by the normalization process If the implementation sets tm_isdst to 0 or 1 when normalizing, then it will remain that way a second time. If the implementation doesn't, your program is in trouble already. I think you're misunderstanding the process. To normalize a struct tm, the implementation should do the equivalent of: - - copy it to a struct tmx - - set the additional fields and tm_isdst as described - - normalize the result - - copy the relevant fields back, except for tm_isdst which is just set to negative, zero, or positive as needed. Nothing stops the implementation setting tm_isdst to 1. The "implementation defined positive value" is used in the struct tmx interpretation of this field, and need not be preserved in the struct tm version (since the normalization process should regenerate it each time). 7.16.2.4 para 3: If tm_isdst is negative the zone information is not available, so the implementation should assume that "local time" has allowed for any DST in effect - in this case, 7.16.2.6 will set X2 to 0 in the algorithm. If tm_isdst is extremely large the behaviour is undefined - see 7.16.2.6 para 2. 7.16.2.6 para 1: A negative tm_isdst, in both struct tm and struct tmx, means "unavailable". If POSIX.1 tries to give it a different meaning, POSIX.1 is broken. Note that you never need to handle negative DST: take all the UTC offsets that the locale uses, and make the most negative the base time with all others being DST (in other words, replace negative "summer" time with positive "winter" time). 7.16.2.6 para 2: These limits were chosen to allow calculations to be done in longs without having to make excessive effort to avoid overflow. Your statement that you can't calculate today's date is wrong: tm_mday = time_t_now / 86400; tm_sec = time_t_now % 86400 However, I do understand your concern. I have no objection in principle to changing these limits, which express a tradeoff between implementer and user; it is up to WG14 as a whole to decide whether to relax or remove them. 7.16.2.6 para 3: I'll address each paragraph separately. (1) You discuss adding 1 day when there's a leap second present. The algorithm assumes that "day" means 86400 seconds at all times, "minute" means 60 seconds, and so on. If you can construct an alternative algorithm I'll be please to look at it. (2) S and D *are* determined - while they are implementation-defined in some circumstances (those when X1 and X2 are used), the implemenation should only be able to pick one value for any given unambiguous input and environment. (3) It is C code (as should be clear from the typeface). There is no possibility of overflow if the limits of paragraph 2 are kept to, and there are no promotions or conversions happening as far as I can tell. (4) There was a typo: it should read: determined by the implementation, or (tm_isdst >= 0 ? tm_isdst : 0) if the offset cannot be determined. (5) I wrestled with this problem myself and failed to come up with a good answer. Effectively D and S are the TAI date and time since some epoch. X1 is the leap second count at the determined time, and X2 is the local offset from UTC (for example, this might be specified by the TZ environment variable and whether DST has taken effect). Both of these are, as you say, dependent on D and S. Again, can you find a better way of expressing it ? (6) Yes, an error does seem to have crept into the definition of D. The first line should read: D = Y * 365 + QUOT(Z,400) * 97 + REM(Z,400) / 4 - REM(Z,400) / 100 + The rest of the expression is correct (including the Y at the start). 7.16.3.5: The zonetime function is the struct tmx version of localtime and gmtime, but instead of offering only 2 choices of zone it offers any zone. You're right that the definition should read TAI-UTC, not UT1-UTC. My error. 7.16.1 para 2: The limits of 14400 are correct. This allows you to adjust by up to 10 days (not 1 day) in an unnormalized time without risking accidentally using _LOCALTIME. Ideally _LOCALTIME would be something like INT_MAX or LONG_MIN. 7.16.2.6 para 3: The macros can't hit overflow with the limits of paragraph 2. Of course, if these limits are changed the macro needs redesigning. It's a pity that C has no defined way to round integer division towards minus infinity and a modulo function that doesn't have a singularity at 0. I know Z can be redefined more simply, but I consider such code too clever for its own good in a definitive document like the Standard. Conclusion: While there are some minor changes that need making, and a couple of others that could be made, the new <time.h> is still IMO better than the old one. It's up to WG14 next week whether to allow the more significant changes that you're asking for, such as a different normalization algorithm. However, if they are ready to consider it, I'm happy to work with you and others to come up with a proposal that is likely to be acceptable. - -- Clive D.W. Feather | Regulation Officer, LINX | Work: <clive(a)linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf(a)i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> Written on my laptop; please observe the Reply-To address ------- End of forwarded message ------- ------- Start of forwarded message ------- Date: Fri, 19 Jun 1998 17:23:06 +0100 From: "Clive D.W. Feather" <clive(a)on-the-train.demon.co.uk> Subject: Re: My Response to PC-US0010 (Eggert) ... I've been doing a little more thought about the normalisation process. What I did was wrote half the process - convert unnormalized time to a number of TAI seconds since some epoch. Rather than writing the other half and risking inconsistencies, it seemed better to simply express it as requiring the normalized time to produce the same result. What I was trying to do originally was ensure that the Standard explains exactly what is meant by (say) day 37 of month 14 of year 1234 (especially when there may or may not be a leap year involved), what happens in 1752 or 1582 or whenever, and so on. To a large extent I don't care what the answers are, so long as there *are* answers. Note that C89 can be reasonably read as generating nonsense answers if there is any inconsistency in the input data. You've made me spot one gap in my logic. If you set tm_leapsecs to 0 before normalizing, the time is effectively TAI, while if you set it to _NO_LEAP_SECONDS it is effectively UTC. The output, however, is always UTC (unless there is no leap second database, in which case tm_leapsecs is set to _NO_LEAP_SECONDS). There's no trivial way to convert it to TAI, unless you know of an algorithm. Do we need a _USE_TAI value as well (indicating that the result should be TAI) ? - -- Clive D.W. Feather | Regulation Officer, LINX | Work: <clive(a)linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf(a)i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> Written on my laptop; please observe the Reply-To address ------- End of forwarded message -------

1 0

comments on draft ISO C9x changes to <time.h>
by Paul Eggert June 16, 1998

June 16, 1998

The ISO committee in charge of the C language has issued a draft for C9x, the next major revision to C. A copy of this (large) document is available in: http://osiris.dkuug.dk/JTC1/SC22/open/2620/n2620/ Section 7.16 of this draft C standard proposes a major overhaul of the functions and datatypes defined in <time.h>. It adds a new data type `struct tmx' that is struct tm extended with the following members: int tm_version; // version number int tm_zone; // time zone offset in minutes from UTC [-1439,+1439] int tm_leapsecs;// number of leap seconds applied void *tm_ext; // extension block size_t tm_extlen; // size of extension block Also, a struct tmx's tm_isdst is the positive number of minutes of offset if DST is in effect. New functions mkxtime, strfxtime use struct tmx instead of struct tm; a new function struct tmx *zonetime (const time_t *timer, int zone); is the rough analog of localtime and gmtime for struct tm. I've submitted the following comments to the ISO committee for their review. A copy of these comments (along with all other US public comments on Committee Draft 1) can be found in: http://osiris.dkuug.dk/JTC1/SC22/WG14/www/docs/n834.htm Category: Feature that should be removed Committee Draft subsection: 7.16 Title: changes to <time.h> need a lot of work and should be withdrawn for now Detailed description: Background and comments Draft C9X introduced a new time struct tmx, new macros _NO_LEAP_SECONDS and _LOCALTIME, and new functions mkxtime, zonetime, and strfxtime. These new functions seem to be an invention of the committee; they are not based on existing practice, and in some cases even ignore longstanding existing practice. The new functions do not address many of the common problems observed with the C89 primitives, notably with mktime. Nor do they add much functionality. For example, a common extension to C, now required by POSIX.1, are reentrant versions of localtime, gmtime, etc. This fills a genuine need, but it's not addressed by draft C9X. There are also other genuine needs that are not addressed; just look at, say, the harsh words about mktime expressed by the author of the tide-calculation program XTide in its source code <http://www.universe.digex.net/~dave/files/xtide-1.6.2.tar.gz>. Draft C9X addresses few of the needs expressed by this author. Here are some more detailed comments on technical shortcomings in this area. Section 7.16.1 paragraph 3. The tm_zone member is an integer number of minutes. However, common practice (e.g. SunOS 4.x, BSD/OS, Linux) is to have a member named tm_gmtoff that is a long number of seconds. This is required for proper support of POSIX.1, which lets the user specify UTC offset to the second; it is also required for proper support of historical applications. For example, the UTC offset of Liberia was 44 minutes and 30 seconds until May 1972, and any program running on, say, Linux with the TZ environment variable set to "Africa/Monrovia" cannot operate correctly with if the UTC offset is required to be a multiple of 60 seconds. The tm_ext and tm_extlen members are an unprecedented kludge in the standard library spec. This is not C++! If the specification for struct tmx is incomplete, this suggests that the editorial work is not done and this type should be withdrawn from the standard. Section 7.16.2.3 paragraph 4. Here, draft C9X added the following new specification for mktime: If the call is successful, a second call to the mktime function with the resulting struct tm value shall always leave it unchanged and return the same value as the first call. (*) This specification is reasonable for mkxtime, but for mktime it requires changes to existing practice in a way that breaks existing software. Existing software often assumes that tm_isdst is either negative, 0, or 1; C89 does not guarantee this, but it is common existing practice, so software that makes this assumption is portable in practice. Unfortunately, specification (*) cannot be satisfied without either adding hidden members to struct tm (which breaks binary compatibility) or by stuffing more information into tm_isdst (which breaks the programs described above). Granted, programs shouldn't assume that a positive tm_isdst is 1, but it's very common in POSIX.1 programs to see expressions like `tzname[tm->tm_isdst]', and these expressions won't work if tm_isdst contains large values. Section 7.16.2.4 paragraph 3. If tm_zone was _LOCALTIME, and if tm_isdst is preposterous (e.g. negative, or INT_MAX), this specification is unclear about what to do. The comments in 7.16.2.6 don't help much. Section 7.16.2.6 paragraph 1. The specification for tm_isdst does not allow for negative daylight-saving time. I don't know of any historical practice for this, but POSIX.1 allows it, and implementations that support POSIX.1 have to allow for it. Section 7.16.2.6 paragraph 2. The limits on ranges for struct tmx members are unreasonable. Common existing practice, for example, is to invoke mktime with a large value for tm_sec to compute a time stamp at some distance from the POSIX.1 epoch. If int and long are the same size, this runs afoul of the new restriction in this section, which limits tm_sec to one-eighth of the potential range. With this limitation I cannot even use mktime to compute today's date on my Unix host from today's time_t value! The other limits are also unnecessary. A well-written mktime should work in the presence of arbitrary values in struct tm members; similarly for mkxtime. Section 7.16.2.6 paragraph 3. There are so many errors in this section that it is hard to determine what is intended. But from what I can tell, the intent is wrong. For example, it seems to be saying that if the implementation supports leap seconds, and if local time is UTC, and if I have a struct tmx that corresponds to 1997-06-30 00:00:00, and then add 1 to tm_mday and invoke mkxtime, I should get 1997-06-30 23:59:60 due to the intervening leap second. This is not what I, the programmer, want or expect! The first sentence in this paragraph reads ``Values S and D shall be determined as follows''. But the rules that follow do not _determine_ S and D; they merely place _constraints_ on S and D. This is because the implementation has some leeway in choosing X1 and X2. It's not clear in this paragraph whether we're looking at C code or mathematics. Are we supposed to be using all the C rules for promotion, conversion, and overflow, or are the calculations to be done using mathematical integer arithmetic? The last sentence in the comment about X1 and X2 is incoherent; I really can't make out what it means. For the implementation to determine X1 and X2, it needs to know what D and S are. But D and S are computed from X1 and X2! More explanation is needed before I can really figure out what's intended here. The definition of D is completely unmotivated, and does not obey the rules of the Gregorian calendar. Among other things, it uses / and % in places where it should use QUOT and REM. (And it can't possibly be right without a `100' in it somewhere. :-) The definition should be rewritten to be something like the following. (Sorry, I haven't tested this, as it's less than 30 minutes before the deadline for submitting comments in the US as this sentence is being written.) D = // day offset since 0000-03-01 // contribution from year Z*365 // number of non-leap days since 0000-03-01 + QUOT(Z, 4) // Every 4 years ends in a leap year. - QUOT(Z, 100) // Every 100 years ends in a nonleap year. + QUOT(Z, 400) // Every 400 years ends in a leap year. // contribution from month; note we start from 03-01 + ((int []){ ...yday offsets, starting in March ...}) [REM(M - 2, 12)] // contribution from day of month + tm_mday - 1 // contribution from time of day + QUOT(SS, 86400) except of course that the expression QUOT(SS, 86400) mishandles leap seconds as described above. Section 7.16.3.5 This new function zonetime is if only marginal use; it seems to be present mostly as a way of defining how mkxtime works. The definition of leap seconds is incorrect. Leap seconds are not a UTC-UT1 offset. The absolute value of the difference between UTC and UT1 is at most 0.9 seconds, by definition. The changes to 7.16 seem to be hastily edited: there are a number of what seem to be typographical errors. The changed text is not explained, and the typos make it hard to understand what was intended. Here are some of the typos that I spotted despite these problems: Section 7.16.1 paragraph 2. _LOCALTIME ``must be outside the range [-14400, +14400].'' Presumably this should be [-1440, +1440], i.e. one day's worth not ten. Section 7.16.2.6 paragraph 3. The definition for QUOT yields numerically incorrect results if (b)-(a) or (b)-(a)-1 overflows. I suggest replacing it with the following definition, which is clearer and free of problems with overflow. This definition relies on C9X's new guarantees about integer division. #define QUOT(a,b) ((a)/(b) - ((a)%(b) < 0)) Similarly, REM can overflow if (b)*QUOT(a,b) overflows. Here is a better version. #define REM(a,b) ((a)%(b) + (b) * ((a)%(b) < 0)) The definition of Z can be written more compactly as: Z = Y - (M < 2); Section 7.16.3.6 paragraph 5. ``If this value is outside the normal range, the characters stored are unspecified.'' What is the ``normal range''? The range as output by localtime, the range of the Gregorian calendar, or the limits as specified in 7.16.2.6? Suggestion Drop all changes to the <time.h> section for this revision of the C Standard. Bring in experts in this area for the next revision of the C Standard. I suggest working together with the members of the Time Zone Mailing list <tz(a)elsie.nci.nih.gov>. Build on existing practice rather than relying on committee inventions, which have been error-prone in this area. If these suggestions is not followed, a lot of changes are needed to this section, as suggested by the above discussion; please contact me if you need more details.

4 5

tzcode1998f.tar.gz
by Olson, Arthur David June 1, 1998

June 1, 1998

The file ftp://elsie.nci.nih.gov/pub/tzcode1998f.tar.gz is now available; it incorporates the addition to localtime.c circulated on the mailing list by Guy Harris. --ado

1 0