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
