- tz - lists.iana.org

Re: Proposal for new ISO C 9x time API
by INFOMAN Inc. Sept. 18, 1998

Sept. 18, 1998

As an addendum to my earlier note, I was informed that "TIMEX" or "Timex" is likely a registered trademark of a watch manufacturer. Consequnetly to avoid difficulties, I suggest that we use the term "timex_" as the reference. To this we can then add "format" "resolve", etc. Another alternative would be to use "timx" as the term Regards - Jake Knoppers <mpereira(a)istar.ca>

3 2

Re: (SC22WG14.6158) (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Douglas.Walls＠Eng.Sun.COM Sept. 17, 1998

Sept. 17, 1998

We can do this in Santa Cruz, formally. >From gwyn(a)arl.mil Thu Sep 17 13:42:50 1998 > >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. >

1 0

Re: (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Douglas A. Gwyn (IST) Sept. 17, 1998

Sept. 17, 1998

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.

1 0

Re: Proposal for new ISO C 9x time API
by INFOMAN Inc. Sept. 17, 1998

Sept. 17, 1998

I would recommend using the term "timex". It is a invented term, a.k.a. coined term or neoligism, to which can be attached the apprpriate definition as well as a note at the end of such defintion of " Formerly known as xtime". "Time" as word is used with multiple meanings and its use can quickly become confusing and inadvertently may have unforeseen results. Having the x precede the _resolves the ambiguity resulting from the x after _ . Trust that this is of some help - Jake Knoppers P.S. For questions of this nature you may find ISO 2788 - Guidelines for the establishment and development of monoligual thesauri and ISO 5964 Guidelines for the establishment and development of multilingual thesauri to be of some help. They include rules for the establishment of terms and controlled vocabularies. If I can be of help elsewhere, SVP let me know.

1 0

About the changes in the counting of time in The Republic of Latvia
by Liene Kanepe Sept. 17, 1998

Sept. 17, 1998

I have tried to collect information about all changes in the counting of time in Latvia. I asked about this matter Scientific Secretary of the Institute of Astronomy of The University of Latvia Dr. paed Mr. Ilgonis Vilks. I also searched the correct data in juridical acts and I found some juridical documents about changes in the counting of time in Latvia from 1981: - Act No.35 of the Council of Ministers of Latvian SSR of 22 January,1981 on the order of counting of time on the territory of Latvian SSR; - Act No.592 of the Council of Ministers of Latvian SSR of 24 September, 1984 on changes in the Act No.35 of the Council of Ministers of Latvian SSR of 22 January,1981 on the order of counting of time on the territory of Latvian SSR; - Act No.81 of the Council of Ministers of Latvian SSR of 22 March,1989 on the changes of counting of time on the territory of Latvian SSR; - Regulations of the Cabinet of Ministers of the Republic of Latvia of 21 January, 1997 on transition to Summer time. Act No.35 of the Council of Ministers of Latvian SSR of 22 January,1981 on the order of counting of time on the territory of Latvian SSR according to the Act No. 925 of the Council of Ministers of USSR of 24 October, 1980 established such order of counting of time: all year round the time of 2nd time zona + 1 hour, in addition turning the hands of the clock 1 hour forward on the 1st April at 0.00 o'clock (GMT 31st March 21:00) and 1 hour backward on the 1st October at 0.00 o'clock (GMT 30 September 20:00). Act No.592 of the Council of Ministers of Latvian SSR of 24 September, 1984 on changes in the Act No.35 of the Council of Ministers of Latvian SSR of 22 January,1981 on the order of counting of time on the territory of Latvian SSR according to the Act No. 967 of the Council of Ministers of USSR of 13 September, 1984 established such order of counting of time on the territory of Latvian SSR: all year round the time of 2nd time zona + 1 hour, in addition turning the hands of the clock 1 hour forward on the last Sunday of March at 02.00 o'clock (GMT 23:00 on the previous day) and 1 hour backward on the last Sunday of September at 03.00 o'clock (GMT 23:00 on the previous day). Act No.81 of the Council of Ministers of Latvian SSR of 22 March,1989 on the changes of counting of time on the territory of Latvian SSR according to the Act No. 227 of the Council of Ministers of USSR of 14 March, 1989 established such order of counting of time: since the last Sunday of March, 1989 in Lithuanian SSR, Latvian SSR, Estonian SSR and Kaliningrad region of Russian Federation all year round the time of 2nd time zona (Moscow time minus one hour). On the territory of Latvia transition to summer time is performed on the last Sunday of March at 02.00 o'clock (GMT 0:00), turning the hands of the clock 1 hour forward . The end of daylight saving time is performed on the last Sunday of September at 03.00 o'clock (GMT 0:00), turning the hands of the clock 1 hour backward. Exception is 26 March of 1989, when we must not turn the hands of the clock. According the Act No.81 of the Council of Ministers of Latvian SSR of 22 March,1989 Act No.35 of the Council of Ministers of Latvian SSR of 22 January,1981 and Act No.592 of the Council of Ministers of Latvian SSR of 24 September, 1984 lost validity. In 1996, when the European Union changed the end of daylight savings time to the last Sunday of October, Latvia had not changed the end of daylight savings time. And this is pardonable for Latvia, because it is not a member - state of the European Union. Latvia changed the end of daylight savings time to the last Sunday of October only in 1997. Then were accepted the Regulations of the Cabinet of Ministers of the Republic of Latvia of 21 January, 1997 on transition to Summer time. According these regulations Act No.81 of the Council of Ministers of Latvian SSR of 22 March,1989 lost validity and was established the same order of daylight savings time settings as in the States of the European Union. From the 1997 Latvia changes from Winter time to Summer time on the last Sunday of March at 3 a.m.(Latvian time) or 1.00 GMT. It changes from Summer time to Winter time on the last Sunday of October at 4 a.m. (Latvian time) or 1 GMT. Here are exact data for Latvia in the period from 1981. |--------------+--------------+--------------+--------------> |The date when |The hour (GMT)|The character |Time offset | |time changes |when time |of time |from GMT for | |were performed|changes were |changes |the Republic | | |performed | |of Latvia | |--------------+--------------+--------------+--------------> >--------------| |Time offset | |from GMT for | |Moscow | |(Russia) | >--------------| |--------------+--------------+--------------+--------------> |31st March, | 21:00 |(+1 h Summer | 4 hours | |1981 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |30 September, | 20:00 | (-1 h Summer | 3 hours | |1981 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |31 st March, | 21:00 |(+1 h Summer | 4 hours | |1982 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |30 September, | 20:00 |(-1 h Summer | 3 hours | |1982 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |31 st March, | 21:00 |(+1 h Summer | 4 hours | |1983 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |30 September,| 20:00 |(-1 h Summer | 3 hours | |1983 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |31 st March, | 21:00 |(+1 h Summer | 4 hours | |1984 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |29 September, | 23:00 |(-1 h Summer | 3 hours | |1984 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |30 th March, | 23:00 | (+1 h Summer | 4 hours | |1985 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |28 September,| 23:00 |(-1 h Summer | 3 hours | |1985 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |29 th March, | 23:00 |(+1 h Summer | 4 hours | |1986 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |27 September, | 23:00 |(-1 h Summer | 3 hours | |1986 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |28 th March, | 23:00 |(+1 h Summer | 4 hours | |1987 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |26 September, | 23:00 |(-1 h Summer | 3 hours | |1987 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |26 th March, | 23:00 |(+1 h Summer | 4 hours | |1988 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |24 September, | 23:00 |(-1 h Summer | 3 hours | |1988 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |25 th March, | 23:00 |(+1 h Summer | | |1989 | |time in all | 3 hours | | | |territory of | | | | |USSR and -1 | | | | |hour in | | | | |Latvia, | | | | |Lithuania and | | | | |Estonia) | | |--------------+--------------+--------------+--------------> >--------------| | | | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |24 September, | 0:00 |(-1 h Summer | 2 hours | |1989 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |24 th March, | 0:00 |(+1 h Summer | 3 hours | |1990 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |29 September, | 0:00 |(-1 h Summer | 2 hours | |1990 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |30 th March, | 0:00 |(-1 h Decree | 3 hours | |1991 | |time in | | | | |Russia, but | | | | |not in Latvia | | | | |and +1 h | | | | |Summer time in| | | | |both states) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |29 September, | 0:00 |(-1 h Summer | 2 hours | |1991 | |time), | | | | | | | |--------------+--------------+--------------+--------------> >--------------| | 2 hours | >--------------| |--------------+--------------+--------------+--------------> |19 th January,| 01:00 |(+ 1 h Decree | 2 hours | |1992 | |time in | | | | |Russia, but no| | | | |changes in | | | | |Latvia) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |28 th March, | 0:00 |(+1 h Summer | 3 hours | |1992 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |26 September, | 0:00 |(-1 h Summer | 2 hours | |1992 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |27 th March, | 0:00 |(+1 h Summer | 3 hours | |1993 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |25 September, | 0:00 |(-1 h Summer | 2 hours | |1993 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |26 th March, | 0:00 |(+1 h Summer | 3 hours | |1994 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |24 September, | 0:00 |(-1 h Summer | 2 hours | |1994 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |25 th March, | 0:00 |(+1 h Summer | 3 hours | |1995 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |23 September, | 0:00 |(-1 h Summer | 2 hours | |1995 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |30 th March, | 0:00 |(+1 h Summer | 3 hours | |1996 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |28 September, | 0:00 |(-1 h Summer | 2 hours | |1996 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |30 th March, | 01:00 |(+1 h Summer | 3 hours | |1997 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |26 October, | 01:00 |(-1 h Summer | 2 hours | |1997 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |29 th March, | 01:00 |(+1 h Summer | 3 hours | |1998 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |25 October, | 01:00 |(-1 h Summer | 2 hours | |1998 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| |--------------+--------------+--------------+--------------> |28 th March, | 01:00 |(+1 h Summer | 3 hours | |1999 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 4 hours | >--------------| |--------------+--------------+--------------+--------------> |31 October, | 01:00 |(-1 h Summer | 2 hours | |1999 | |time) | | |--------------+--------------+--------------+--------------> >--------------| | 3 hours | >--------------| In the period from the end of the Second World War on the territory of Latvia (13 October, 1944 for Riga) until the 31st March, 1981, GMT 21:00 the time offset from GMT for Latvia was 3 hours. It seems, that before 13 October, 1944 it was 2 hours, except the period, when Latvia was incorporated in the Soviet Union (approximatly from 05 August, 1940 until 21 June, 1941) and the period, when during the Second World War Latvia was occupied by Germany. If I find the more correct data about the time offset from GMT for Latvia in the period before 1944, I will mail You. With the best regards from The Republic of Latvia, Riga Liene Kanepe

1 0

Re: Proposal for new ISO C 9x time API
by Ken Pizzini Sept. 16, 1998

Sept. 16, 1998

In message <13823.62501.12960.906883@localhost>, Nathan Myers <ncm(a)cantrip.org> wrote: > The names strfxtime, xtime_make, and xtime_breakup are inconsistent > and not ideally chosen. May I suggest instead > > xtime_format: "To plan or arrange in a specified form" > xtime_compose: "To make or create by putting together parts or elements." > xtime_resolve: "To separate (something) into constituent parts." > > respectively? (Quotes are from the Random House unabridged dictionary.) There is an old tradition of language design that the language and its libraries strongly avoid using identifiers starting with the letter "x" --- a desperate application writer can then blithely prepenend an "x" to all its first-choice identifiers and be safe. I'd much prefer to see this tradition upheld; perhaps: timex_format, timex_compose, timex_resolve or time_xformat, time_xcompose, time_xresolve instead? --Ken Pizzini

1 0

Tony Milton/Technology/UK/PARIBAS is out of the office.
by Tony_Milton＠paribas.com Sept. 15, 1998

Sept. 15, 1998

I will be out of the office from 12 September 1998 until 21 September 1998. I will respond to your message when I return. ----------------------------------------------------------------------------- This message is confidential; its contents do not constitute a commitment by Paribas except where provided for in a written agreement between you and Paribas. Any unauthorised disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately. Ce message est confidentiel ; son contenu ne repr�sente en aucun cas un engagement de la part de Paribas sous r�serve de tout accord conclu par �crit entre vous et Paribas. Toute publication, utilisation ou diffusion, m�me partielle, doit �tre autoris�e pr�alablement. Si vous n'�tes pas destinataire de ce message, merci d'en avertir imm�diatement l'exp�diteur.

1 0

Re: (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Keld J|rn Simonsen Sept. 15, 1998

Sept. 15, 1998

> Paul Eggert wrote: > > > > Also, Clive Feather [...] has proposed that a new <time.h> > > section be written to address these problems. I welcome this > > proposal, and would like to contribute. However, I believe that it's > > too late in the standardization process to introduce major > > improvements to <time.h>, as there will be insufficient time to gain > > implementation experience with these changes, experience that is > > needed for proper review. > > I also think it may be too late for incorporating huge changes > in the time functions, as Clive lastly proposed. > I am also reluctant to introduce such changes *after* the FCD > stage (correct me if I am wrong, but I see it as contrary to > what a FCD should be, and it may raise virulent formal > objections later, at FDIS stage). We can do any changes we like from the FCD ballot, this is a normal CD ballot and we are not restricted to minor changes. Keld

1 0

Re: (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Antoine Leca Sept. 15, 1998

Sept. 15, 1998

Paul Eggert wrote: > > Also, Clive Feather [...] has proposed that a new <time.h> > section be written to address these problems. I welcome this > proposal, and would like to contribute. However, I believe that it's > too late in the standardization process to introduce major > improvements to <time.h>, as there will be insufficient time to gain > implementation experience with these changes, experience that is > needed for proper review. I also think it may be too late for incorporating huge changes in the time functions, as Clive lastly proposed. I am also reluctant to introduce such changes *after* the FCD stage (correct me if I am wrong, but I see it as contrary to what a FCD should be, and it may raise virulent formal objections later, at FDIS stage). > Instead, I propose that <time.h>'s problems be fixed by removing the > struct-tmx-related changes to <time.h>, reverting to the the current > ISO C standard (C89); we can then come up with a better <time.h> for > the next standard (C0x). Another way may be to back up to C90 state, as Paul proposed, and then to publish the output of the experts working in this area in the form of an amendment to the standard, to be published around 2002-2003 (to be compared with 2010 for C0X). Is it practicable? John? Antoine

1 0

Summary of problems with draft C9x <time.h>, and a proposed fix
by Paul Eggert Sept. 14, 1998

Sept. 14, 1998

Rex Jaeschke, NCITS/J11 chair, recently sent me a copy of document J11/98-048, which contains the disposition by J11 of my public review comments regarding the C9x standard Committee Draft (CD) 1 (CD 9899, Ballot Document N2620). One of my comments was not satisfactorily resolved, and I'd like to follow up in the hope of improving the eventual standard. I'm referring to Comment 14 in US0011 (1998-03-04), my comment about problems in the struct-tmx-related changes by CD 1 to <time.h>. Unfortunately, many of these problems remain in CD 2, and I've since learned of other problems. I summarize these remaining problems in Appendix 1 below. Also, Clive Feather (who I understand is responsible for most of the <time.h> changes in CDs 1 and 2) has proposed that a new <time.h> section be written to address these problems. I welcome this proposal, and would like to contribute. However, I believe that it's too late in the standardization process to introduce major improvements to <time.h>, as there will be insufficient time to gain implementation experience with these changes, experience that is needed for proper review. Instead, I propose that <time.h>'s problems be fixed by removing the struct-tmx-related changes to <time.h>, reverting to the the current ISO C standard (C89); we can then come up with a better <time.h> for the next standard (C0x). In other words, I propose the following: * Change <time.h> to define only the types and functions that were defined in C89's <time.h>, and to remove a new requirement on mktime. Appendix 2 gives the details. * Work with Clive Feather and other interested parties to write and test a revised <time.h> suitable for inclusion in C0x. Please let me know of any way that I can further help implement this proposal. ------------------------------------------------------------ Appendix 1. Problems in the struct-tmx-related part of <time.h> Here is a summary of technical problems in the struct-tmx-related part of CD 2 (1998-08-03), section 7.23. The problems fall into two basic areas: * struct tmx is not headed in the right direction. The struct-tmx-related changes do not address several well-known problems with C89 <time.h>, and do not form a good basis for addressing these problems. These problems include the following. - Lack of precision. The standard does not require precise timekeeping; typically, time_t has only 1-second precision. - Inability to determine properties of time_t. There's no portable way to determine the precision or range of time_t. - Poor arithmetic support for the time_t type. difftime is not enough for many practical applications. - The new interface is not reentrant. A common extension to C89 is the support of reentrant versions of functions like localtime. This extension is part of POSIX.1. There's no good reason (other than historical practice) for time-related functions to rely on global state; any new extensions should be reentrant. - No control over time zones. There's no portable way for an application to inquire about the time in New York, for example, even if the implementation supports this. - Missing conversions. There's no way to convert between UTC and TAI, or between times in different time zones, or to determine which time zone is in use. - No reliable interval time scale. If the clock is adjusted to keep in sync with UTC, there's no reliable way for a program to ignore this change. - One cannot apply strftime to the output of gmtime, as the %Z and %z formats may be misinterpreted. (Credit: I've borrowed many of the above points from discussions by Clive Feather and Markus Kuhn.) * struct tmx has several technical problems of its own. Even on its own terms, struct tmx has several technical problems that would need to be fixed before being made part of a standard. These problems include the following. - In 7.23.1 paragraph 5, struct tmx's tm_zone member counts minutes. This disagrees with common practice, which is to extend struct tm by adding a new member tm_gmtoff that is UTC offset in seconds. The extra precision is needed to support old time stamps -- UTC offsets that were not a multiple of one minute used to be quite common, and in at least one locale this practice did not die out until 1972. - The tm_leapsecs member defined by 7.23.1 paragraph 5 is an integer, but it is supposed to represent TAI - UTC, and this value is not normally an integer for time stamps before 1972. Also, it's not clear what this value should be for time stamps before the introduction of TAI in the 1950s. - The tm_ext and tm_extlen members defined by 7.23.1 paragraph 5 use a new method to allow for future extensions. This method has never before been tried in the C Standard, and is likely to lead to problems in practice. For example, the draft makes no requirement on the storage lifetime of storage addressed by tm_ext. This means that an application cannot reliably dereference the pointer returned by zonetime, because it has no way of knowing when the tm_ext member points to freed storage. - 7.23.2.3 paragraph 4 adds the following requirement for mktime not present in C89: 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 requirement was inspired by the struct-tmx-related changes to <time.h>, but it requires changes to existing practice, and it cannot be implemented without hurting performance or breaking binary compatibility. For 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 select the time_t by inspecting tm_isdst, since both times are standard time. On examples like these, C89 allows mktime to return different time_t values for the same input at different times during the execution of the program. This is common existing practice, but it is prohibited by this new requirement. It's possible to satisfy this new requirement by adding a new struct tm member, which specifies the UTC offset. However, this would break binary compatibility. It's also possible to satisfy this new requirement by always returning the earlier time_t value in ambiguous cases. However, this can greatly hurt performance, as it's not easy for some implementations to determine that the input is ambiguous; it would require scouting around each candidate returned value to see whether the value might be ambiguous, and this step would be expensive. - The limits on ranges for struct tmx members in 7.23.2.6 paragraph 2 are unreasonably tight. For example, they disallow the following program on a POSIX.1 host with a 32-bit `long', since `time (0)' currently returns values above 900000000 on POSIX.1 hosts, which is well above the limit LONG_MAX/8 == 268435455 imposed by 7.23.2.6. #include <time.h> struct tmx tm; int main() { char buf[1000]; time_t t = 0; /* Add current time to POSIX.1 epoch, using mkxtime. */ tm.tm_version = 1; tm.tm_year = 1970 - 1900; tm.tm_mday = 1; tm.tm_sec = time (0); if (mkxtime (&tm) == (time_t) -1) return 1; strfxtime (buf, sizeof buf, "%Y-%m-%d %H:%M:%S", &tm); puts (buf); return 0; } The limits in 7.23.2.6 are not needed. A mktime implementation need not check for overflow on every internal arithmetic operation; instead, it can cheaply check for overflow by doing a relatively simple test at the end of its calculation. - 7.23.2.6 paragraph 3 contains several technical problems: . In some cases, it requires mkxtime to behave as if each day contains 86400 seconds, even if the implementation supports leap seconds. For example, if the host supports leap seconds and uses Japan time, then using mkxtime to add 1 day to 1999-01-01 00:00:00 must yield 1999-01-01 23:59:59, because there's a leap second at 08:59:60 that day in Japan. This is not what most programmers will want or expect. . The explanation starts off with ``Values S and D shall be determined as follows'', but the code that follows does not _determine_ S and D; it consults an oracle to find X1 and X2, which means that the code merely places _constraints_ on S and D. A non-oracular implementation cannot in general determine X1 and X2 until it knows S and D, so the code, if interpreted as a definition, is a circular one. . The code suffers from arithmetic overflow problems. 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. . The code does not declare the types of SS, M, Y, Z, D, or S, thus leading to confusion. Clearly these values cannot be of type `int', due to potential overflow problems like the one discussed above. It's not clear what type would suffice. . The definition for QUOT yields numerically incorrect results if either (b)-(a) or (b)-(a)-1 overflows. Similarly, REM yields incorrect results if (b)*QUOT(a,b) overflows. . The expression Y*365 + (Z/400)*97 + (Z%400)/4 doesn't match the Gregorian calendar, which has special rules for years that are multiples of 100. . The code is uncommented, so it's hard to understand and evaluate. For example, the epoch (D=0, S=0) is not described; it appears to be (-0001)-12-31 Gregorian, but this should be cleared up. - 7.23.3.7 says that the number of leap seconds is the ``UTC-UT1 offset''. It should say ``UTC - TAI''. ------------------------------------------------------------ Appendix 2. Details of proposed change to <time.h> Here are the details about my proposed change to <time.h>. This change reverts the <time.h> part of the standard to define only the types, functions, and macros that were defined in C89's <time.h>. It also removes the hard-to-implement requirement in 7.23.2.3 paragraph 4. * 7.23.1 paragraph 2. Remove the macros _NO_LEAP_SECONDS and _LOCALTIME. * 7.23.1 paragraph 3. Remove the type `struct tmx'. * 7.23.1 paragraph 5 (struct tmx). Remove this paragraph. * 7.23.2.3 paragraph 3 (mktime normalization). Remove this paragraph. * 7.23.2.3 paragraph 4. Remove the phrase ``and return the same value''. It's not feasible to return the same value in some cases; see the discussion of 7.23.2.3 paragraph 4 above. * 7.23.2.4 (mkxtime). Remove this section. * 7.23.2.6 (normalization of broken-down times). Remove this section; this means footnote 252 will be removed. * 7.23.3 paragraph 1. Remove the reference to strfxtime. * 7.23.3.6 (strfxtime). Remove this section. * 7.23.3.7 (zonetime). Remove this section.

1 0