From seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt Thu Dec 4 08:57:02 1986 To: elsie!ado Subject: ctime proposal ado, Please feel free to circulate this to the ctime community.
Guy Harris has sent me corrections and additions to the latest versions of the time zone stuff--and, in particular, has added some code to "newctime.c" both for better System V compatibility and to provide the "mktemp" function specified in recent versions of the X3J11 (a.k.a. C Standard) committee's drafts. If you'd like to receive the new versions, let me know.
mktemp is really mktime, I assume.
Here's a table summarizing the current state of agreement among various existing and proposed sets of time-handling functions. One idea for getting better agreement follow the table.
I have added X3J11 and X/OPEN to the extent that I understand them. I have also restated HP to reflect what is currently implemented and available, not what I thought we might get from a compromise package. Variables and functions provided by. . . V.2 4.3 HP X3J11 X/OPEN ado guy ------------------------------------------------------------------------------ ctime() yes yes yes ?? yes yes yes localtime() yes yes yes ?? yes yes yes gmtime() yes yes yes ?? yes yes yes asctime() yes yes yes ?? yes yes yes long timezone yes no yes ?? yes no yes int daylight yes no yes ?? yes no yes char *tzname[2] yes no yes ?? yes yes yes tzset() yes no yes ?? yes yes yes timezone() no yes no ?? no no no (5) dysize(int y) no yes no ?? no no yes (1) nl_ctime no no yes ?? yes no no (4) nl_asctime no no yes ?? yes no no (4) nl_cxtime no no yes ?? yes no no (4) nl_ascxtime no no yes ?? yes no no (4) strftime no no no yes no no no (4) zonetime() no no no ?? no yes yes settz() no no no ?? no yes yes mktime() no no no yes no no yes (2) gmtime2() no no yes ?? no no yes (3)
(1) This undocumented Berkeley function returns 366 if its (single integer) argument is divisible by four; it returns 365 otherwise.
This is not strictly correct for the Gregorian Era, although it is for 1970 to 2037 (or was that 190? to 2037) multiples of 100 should return 365 except multiples of 100 and 400 which should return 366.
(2) As described in recent X3J11 committee drafts, this function ". . .converts the broken-down time, expressed as local time, in the [struct tm] pointed to by [it's argument] into a calendar time value with the same encoding as that of the values returned by the time function."
(3) gmtime2 is the inverse of gmtime, converting a time value in the tm structure into a calendar time value. Currently it is static and undocumented. (4) nl_ctime, nl_asctime, nl_cxtime, nl_ascxtime, and strftime all are designed add a) formatting capability and b) locale-specific month and day names. These 5 can easily be merged to one or two routines. For those who have not seen X3J11/86-125R by D. F. Prosser, strftime() is defined as: int strftime(str, n, format, tp) char *str; /* return string */ int n; /* maximum string length */ char *format; /* format string similar to date + */ struct tm *tp; /* time value structure */ (5) timezone() is not adequate for an international standard. It assumes that the time zone name (EST) or DST name (EDT) can be derived simply from the offset from GMT.
A way I see of getting better agreement is to eliminate "settz" and "zonetime". The capabilities these functions provide can, for the most part, be provided by direct manipulation of the environment variable TZ, combined with "tzset" calls (assuming, of course, that good-enough functions for environment manipulation are available.) True, it means more work for programmers interested in changing time zones-- but the need to do so is rare, and the extra work will pay off since the results of the work will be somewhat more portable (in particular, will be more portable to existing System V environments).
Any comments on the above idea? Any other ideas?
May I suggest the following be done immediately: 1) From the subset above, I would like to suggest that we select the following: V.2 4.3 HP X3J11 X/OPEN ado guy ------------------------------------------------------------------- ctime() yes yes yes ?? yes yes yes localtime() yes yes yes ?? yes yes yes gmtime() yes yes yes ?? yes yes yes asctime() yes yes yes ?? yes yes yes long timezone yes no yes ?? yes no yes int daylight yes no yes ?? yes no yes char *tzname[2] yes no yes ?? yes yes yes tzset() yes no yes ?? yes yes yes dysize(int y) no yes no ?? no no yes strftime() no no no yes no no no strasftime() no no no no no no no gmtime2() no no yes ?? no no yes 2) Add long tm_tzadj to tm structure. It is incorrect to assume that one hour should be added or subtracted based on tm_isdst. For example, parts of Indiana are on CDT when tm_isdst is true and EST when tm_isdst is false. This will correctly indicate whether tzname[0] or tzname[1] should be used. However the actual offset from GMT does not change. This gives analogs to daylight and timezone external variables which are applicable to the time value contained in the tm structure. struct tm { int tm_sec; int tm_min; int tm_hour; int tm_mday; int tm_mon; int tm_year; int tm_wday; int tm_yday; int tm_isdst; long tm_tzadj; }; 3) Select gmtime2() over mktime() since it is a true inverse of gmtime(). The result of gmtime2() can trivially be modified to correct for local time using tm_tzadj mentioned above. 4) Define a strasftime() which is (as a parallel to ctime()): return(strftime(str, n, format, localtime(clock)); 5) Retain the System V Release 2 syntax for TZ. In addition, augment it to handle handle minutes such as TZ=CST-9:30CDT for for Queensland, Australia. 6) settz("value") may be approximated as putenv("TZ=value"); tzset() 7) Augment field descriptors for date(1) to parallel X3J11 strftime() proposal. In most cases strftime() uses date(1) descriptors. In the future we should also address: 8) Look at time() values beyond 1970 to 2037. P1003 has already done some work here. 9) Look at the difference between GMT and UTC (Universal Coordiated Time -- this is the correct name and correct abbreviation). I believe that GMT uses seconds of variable length to accommodate the inaccuracies of nature. UTC on the other hand uses leap seconds. It is UTC which is generally available from WWV and other international time standard sources. Ron Tolley