In this letter I'll try to: 1. Recap the discussion of the question "Should TZ, or something else (such as TIMEZONE), be used as the environment variable where time zone information is kept?" 2. Throw in my own two cents on the discussion of "How does the environment variable TZ get initialized in the first place?" 3. Summarize different ways programs might use to get time zones other than the one specified in the environment--I trust other folks will discuss this further. I've also attached a copy of my latest revised ctime manual page. 1. A few folks (me included) see putting time zone information in an environment variable with a new name (such as TIMEZONE) as a good thing. Doing so could avoid problems for "old" programs run with something such as TZ=US/Eastern or TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 in their environments. Most folks on this mailing list, though, think it best to stick with TZ. It's an environment variable whose purpose is already clearly understood as being a repository of time zone information, and it would be a nuisance to have both it and TIMEZONE. So: I'll stick with using TZ (and will also hope that someone can come up with an explanation for doing so that's both brief and more compelling that the one in this paragraph). 2. As to how TZ should be initialized--I'd hope that the standard(s) will end up providing a scheme that doesn't require TZ to be initialized at all, and that if TZ is absent from the environment then programs will deliver "the best available approximation to local wall clock time." In a scheme where time zone information is kept in files, this is easy: you just, for example, do a ln /etc/zoneinfo/US/Eastern /etc/zoneinfo/localtime or ln /etc/zoneinfo/Moon/Darkside /etc/zoneinfo/localtime and set up the time handling functions to load things from "/etc/zoneinfo/localtime" if TZ is absent from the environment. As others have shown, in a "non-file" scheme it's also possible to cope with the absence of TZ--although more code is needed for coping purposes (since you need to both know the name of the file to be used and need to interpret its contents). Either way, I think that the time zone functions are the right place to handle dealing with what local time is-- and that init is the wrong place. 3. Folks have now outlined three ways for programs to ask for variant time zones: a. The "ctime.least" method outlined in some of Ron Tolley's manual pages, in which "localtime" simply examines the TZ environment variable each time localtime is called. To get a variant time zone, you just set up TZ with the variant before calling localtime (either directly or indirectly via ctime). b. The System V Release 2.0 method, in which you must set up the environment variable TZ and then call the function "tzset" to get stuff read out of TZ for future use by localtime. c. The settz("whatever") approach, in which an explicit call is provided for switching to a variant time zone, with no fiddling of the environment required. These days, I favor standardizing the second approach. If the first approach is standardized, I think there'll be too much code written along these lines: putenv("TZ", "whatever"); printf("%s", ctime(&t)); that won't do what's expected when it's moved to System V Release 2.0 systems. Yes, requiring the "tzset" call after the "putenv" *is* a nuisance--but better a nuisance than worng results. And: while I'd favor having the standard(s) specify that local wall clock time should be used if TZ is absent from the environment, I think we'd best recognize that existing systems *don't* do so. For those applications that *must* have local wall clock time, I'd provide a standard function "tzsetwall" (the name is subject to change) that sets things up to use the best available approximation of local wall clock time regardless of what's in the environment (with a tip of the hat to Guy Harris for pointing out that this is the easy way to handle things). So: if you only *wanted* local wall clock time, you could use the code: { char ** savedenv; extern char ** environ; static char * fake[1]; savedenv = environ; environ = fake; tzset(); environ = savedenv; } and end up with code that would compile on any UNIX system and would deliver local wall clock time on any POSIX system. If, on the other hand, you *needed* local wall clock time, you would use the code: tzsetwall(); which would deliver local wall clock time on any POSIX system, and wouldn't compile at all on any existing UNIX system. Yes, you wouldn't get any results at all--but not gettting any results is better than getting worng results. --ado .TH CTIME 3 .SH NAME ctime, localtime, gmtime, asctime, tzset, tzsetwall \- convert date and time to ASCII .SH SYNOPSIS .nf .B extern char *tzname[2]; .PP .B void tzset() .PP .B void tzsetwall() .PP .B char *ctime(clock) .B long *clock; .PP .B #include <time.h> .PP .B char *asctime(tm) .B struct tm *tm; .PP .B struct tm *localtime(clock) .B long *clock; .PP .B struct tm *gmtime(clock) .B long *clock; .fi .SH DESCRIPTION .I Tzset uses the value of the environment variable .B TZ to set time conversion information used by .IR localtime . If .B TZ does not appear in the environment, the best available approximation to local wall clock time is used by .IR localtime . .if !\nX \{\ If .B TZ does appear in the environment, .I localtime will only work correctly if its value is one of an implementation-defined set of values.\} .el \{\ If the value of .B TZ begins with a slash, it is used as the absolute pathname of the .IR tzfile (5)-format file from which to read the time conversion information; if .I zonename begins with some other character, it is used as a pathname relative to a system time conversion information directory. \} .PP .I Tzsetwall sets things up so that .I localtime returns the best available approximation of local wall clock time. .PP .I Ctime\^ converts a long integer, pointed to by .IR clock , representing the time in seconds since 00:00:00 GMT, January 1, 1970, and returns a pointer to a 26-character string of the form .br .ce Thu Nov 24 18:22:48 1986\\n\\0 .br All the fields have constant width. .PP .IR Localtime\^ and .I gmtime\^ return pointers to ``tm'' structures, described below. .I Localtime\^ corrects for the time zone and any time zone adjustments (Daylight Savings time in the U.S.A.); before doing so, .I localtime\^ calls .I tzset\^ if .I tzset\^ has not been called in the current process. After filling in the ``tm'' structure, .I localtime sets the .BR tm_isdst 'th element of .B tzname to a pointer to an ASCII string that's the time zone abbreviation to be used with .IR localtime 's return value. .PP .I Gmtime\^ converts to Greenwich Mean Time (GMT). .PP .I Asctime\^ converts a time value contained in a ``tm'' structure to a 26-character string, as shown in the above example, and returns a pointer to the string. .PP Declarations of all the functions and externals, and the ``tm'' structure, are in the .B <time.h>\^ header file. The structure declaration is: .RS .PP .nf struct tm { int tm_sec; /\(** seconds (0 - 59) \(**/ int tm_min; /\(** minutes (0 - 59) \(**/ int tm_hour; /\(** hours (0 - 23) \(**/ int tm_mday; /\(** day of month (1 - 31) \(**/ int tm_mon; /\(** month of year (0 - 11) \(**/ int tm_year; /\(** year \- 1900 \(**/ int tm_wday; /\(** day of week (Sunday = 0) \(**/ int tm_yday; /\(** day of year (0 - 365) \(**/ int tm_isdst; /\(** is DST in effect? \(**/ }; .fi .RE .PP .I Tm_isdst\^ is non-zero if a time zone adjustment such as Daylight Savings time is in effect. .SH SEE ALSO .if \nX tzfile(5), getenv(3), time(2) .SH BUGS The return values point to static data whose content is overwritten by each call. .. @(#)newctime.3 2.9