- tz - lists.iana.org

Resolved timezone issue? Other issues. New ctime manual page
by ado Dec. 16, 1986

Dec. 16, 1986

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

1 0

mod.std.unix announcement?
by ado Dec. 16, 1986

Dec. 16, 1986

If there's no objection, I'd like to announce the existence of the time zone mailing list in a mod.std.unix article. Let me know if there are problems; if not, I plan to submit an article this Thursday or Friday. --ado

1 0

Parsing /etc/TIMEZONE
by seismo!cuuxb!dlm Dec. 15, 1986

Dec. 15, 1986

I wrote a simpler and better parse of /etc/TIMEZONE. Also note that since /etc/init already does so one could steal its code. He is my short parse. Note, it does parse System V Release 3.1 versions which have OTHER lines of garbage (comments and such): === #include <stdio.h> #include <string.h> char def_timezone[] = "GMT0"; char * gettz() { FILE * tzfp; register char *bp; register char *tbp; static char buf[132]; if ( (tzfp = fopen("/etc/TIMEZONE", "r") ) == NULL) { return(def_timezone); } while ( fgets(buf, sizeof buf, tzfp) != NULL ) { if ( buf[0] == '#' || buf[0] == '\n' ) continue; buf[strlen(buf)-1] = '\0'; /* strip newline */ if ( strchr(buf, '=') == NULL ) continue; for (tbp = buf; ; ) { bp = strtok(tbp, "; \t"); if ( bp == NULL ) break; /* should be xx=xxx; */ if ( strchr(bp, '=') != NULL && strncmp( bp, "TZ=",3) == 0 ) break; tbp = NULL; } fclose(tzfp); return(strchr(bp,'=')+1); } fclose(tzfp); return(def_timezone); } ===== Note that we use the stdio AND SysV string functions. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!sun!guy Dec. 13, 1986

Dec. 13, 1986

> 2. Init (/etc/init == process 1) reads and parses this file and > sets the environment of all children processes with the TZ > variable... There is no guarentee that some fiend doesn't step on the value before passing it to someone else. Even if there are no fiends, there may be remote users. One needs a mechanism to find out the correct timezone information from an unimpeachable source. "Source'ing" /etc/timezone is not slick if your process isn't the Bourne/Korn shell. True, but assuming that "/etc/TIMEZONE" has the format TZ=<name> that file can easily be parsed by a program other than a shell. (Nothing more is needed in "/etc/TIMEZONE"; e.g., if you want to export "TZ" after fetching it from "/etc/TIMEZONE", you just do "export TZ" after sourcing "/etc/TIMEZONE". Given that, if the argument to "settz" were "(char *)NULL", "settz" could fetch the machine's local time zone by doing something like register int fd; static char tzbuf[SIZE + 1]; register int i; fd = open("/etc/timezone, O_RDONLY); if ((i = read(fd, tzbuf, SIZE + 1)) < 0) return (-1); /* * The "SIZE + 1" is a hack to detect overly-long files. * We advertise SIZE as the maximum size, and if there's anything * after it, we complain. */ if (i == SIZE + 1) return (-1); if (i < 4) return (-1); /* doesn't start with "TZ=" */ if (strncmp(tzbuf, "TZ=", 3) != 0) return (-1); /* doesn't start with "TZ=" */ if (tzload(tzbuf + 3, &s) == -1) return (-1);

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!nbires!vianet!devine Dec. 13, 1986

Dec. 13, 1986

My, this proposal sounds familiar :-). I've since been won over to the stick-the-stuff-in-a-file-and-use-functions party. > 2. Init (/etc/init == process 1) reads and parses this file and > sets the environment of all children processes with the TZ variable... There is no guarentee that some fiend doesn't step on the value before passing it to someone else. Even if there are no fiends, there may be remote users. One needs a mechanism to find out the correct timezone information from an unimpeachable source. "Source'ing" /etc/timezone is not slick if your process isn't the Bourne/Korn shell. > 3. The TZ variable has new syntax and fields. First as sample > TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 > Comments: > The new syntax for TZ allows for any time zone rule, but only > allows ONE change per year. The varialbe must be modified and > reset for the year being printed. Thus is TZ is set for 1987 a > full ctime for a previous year will result in odd information for > a few days each spring and fall (US). This goes to the heart of the proposal. I tried hard to convince myself that one year's definition suffices. However, it is certainly possible to do multiple years and to hide the nastiness as well by using a collection of files. When I proposed a redefinition of TZ to hold more info, it was in part because I didn't want to break UNIX conventions. I guess that is one of the underlying concern in this proposal too. Unfortunately they were always broken with respect to correctly handling the world's variety of timezones. Bob Devine

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!sun!guy Dec. 12, 1986

Dec. 12, 1986

1. The TZ environment is set and maintained in the file /etc/TIMEZONE and is a Bourne shell file that can be sourced ( . /etc/TIMEZONE) by any one who wishes. You'd better make that "can be source by any *Bourne shell* that wishes". There is no guarantee whatosever that a given user will ever have a Bourne shell running in their session; e.g., "uucp" usually has "uucico" as its login shell. "uucico" would have to read "/etc/TIMEZONE" itself, and pass the first line in that file to "putenv" after stripping off the trailing newline (remember, you do NOT want to permit the user to do TZ=EST5EDT uucp ... in order to force "uucico" to think it's after 11PM and thus force it to make the call to the target system immediately). 3. The TZ variable has new syntax and fields. First as sample TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 This is totally wrong. For one thing, as you point out later, it makes the incorrect assumption that only the rules for the current year are of interest. For another, it sets TZ to a complicated string which also requires work to generate; how many of you who don't happen to have calendars that give Julian dates on every day page want to go through the trouble of figuring Julian dates out? (This is also a botch in the S5 accounting routines; you have to provide the Julian date of all the days to be considered holidays. A computer can figure that out much better than a human can.) Both Arthur Olson's and HP's schemes, which put the rules into a file and which just provide the *name* of the file to fetch them from, are vastly superior. Olson's code includes a compiler that makes generating the rules quite easy. 5. A new sequences of time functions [setcftime,ascftime,cftime] Oh boy, just what we need, a *third* set of functions, different both from ANSI C and from the HP-X/Open ones! AT&T-IS should either drop these functions in favor of one of the existing ones or get one or the other or both bodies to adopt theirs. 6. A variable LANGUAGE is used to specifiy the language of the output [default is ENGLISH with /lib/cftime/usa_english ] the default file. Files in /lib/cftime specify the default names and abbreviations of the days and months, as well as default strings for date and cftime (Europeans use dd/mm/yy and USA uses mm/dd/yy) and such. HP's scheme, at least as presented in the X/Open stuff I saw, is much better. Instead of a set of files specific to time formatting, they provide a general "string catalog", so that you can fetch messages, time and date format strings, etc. for the particular language and cultural environment. Having a "/lib/cftime" directory is just a hack. (Also, what does the LANGUAGE variable contain? For the US, would it be ENGLISH or "usa_english"? The former is incorrect; I believe the date format in Britain, for example, is different from that in the US, so just stating the language is insufficient.) 7. The environment variable CFTIME can be used to specify the default format string for cftime related functions and programs -- date now uses cftime. Why is this necessary, if there is a LANGUAGE variable? Comments: The new syntax for TZ allows for any time zone rule, but only allows ONE change per year. The varialbe must be modified and reset for the year being printed. Thus is TZ is set for 1987 a full ctime for a previous year will result in odd information for a few days each spring and fall (US). It also doesn't look like it can handle things like South Australia's switch from CST to EST. It seems like a trivial change to store a table of TZ variables for each year. I hope by "store a table" you mean "store a table *in a file*". This table could get pretty big if you really want it to specify the rules for the entire range of valid UNIX times. All in all, none of this is very good. Others have done it much better; AT&T-IS would be best advised to leave this *all* out of the SVID, and be prepared to do it differently in future releases.

1 0

ATT System V Rlease 3.1 and Timezones
by seismo!cuuxb!dlm Dec. 11, 1986

Dec. 11, 1986

The P.55 Timezone Proposal has been sent to a low level developer at ATT Summit, NJ. The current reading is that due to schedule pressures there is little likely-hood of anything being adopted by ATT unless it is part of ANSI C for the next year or so. It also appears that none of the subscribers to the mailing list are aware of changes and directions for recent releases of ATT software so here is a summary: 1. The TZ environment is set and maintained in the file /etc/TIMEZONE and is a Bourne shell file that can be sourced ( . /etc/TIMEZONE) by any one who wishes. 2. Init (/etc/init == process 1) reads and parses this file and sets the environment of all children processes with the TZ variable. It is thus propagated through cron, login and su. [And thus to csh (just for Mark :-) ]. (Feature in System V Release 3.1 and following). 3. The TZ variable has new syntax and fields. First as sample TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 This says the offset from GMT is 3 hours 15 minutes and 23 seconds; Alternate time starts on Julian day 281 at 2am and reverts on Julian Day 315 at 1am. Alternate time is offset from GMT by 2 hours 25 minutes and 12 seconds. Note negative time offsets are East of Greenwich and thus -5:00 ougt to be somewhere in Russia. An example of a Southern Hemishpere setting for perhaps the Cook Islands (not to be considered a real thing, just a cooked example (no pun): TZ=KDT9:30KST10:00;64/5:00,303/20:00 For TZ strings with no time specified for the change (Julian date only) the change of time defaults to midnight local time. 4. If no TZ variable is set or exists default timezone rules are for GMT. 5. A new sequences of time functions [setcftime,ascftime,cftime] allow variable formats for time (similar in concept for the funny formats for date). int cftime(buf, fmt, clock) char *buf, *fmt; time_t clock; 6. A variable LANGUAGE is used to specifiy the language of the output [default is ENGLISH with /lib/cftime/usa_english ] the default file. Files in /lib/cftime specify the default names and abbreviations of the days and months, as well as default strings for date and cftime (Europeans use dd/mm/yy and USA uses mm/dd/yy) and such. 7. The environment variable CFTIME can be used to specify the default format string for cftime related functions and programs -- date now uses cftime. Comments: The new syntax for TZ allows for any time zone rule, but only allows ONE change per year. The varialbe must be modified and reset for the year being printed. Thus is TZ is set for 1987 a full ctime for a previous year will result in odd information for a few days each spring and fall (US). It seems like a trivial change to store a table of TZ variables for each year. The cftime additions are useful for international situations but still the TZ rules are a bit parochial. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

Re: TZ, ZONE, TIMEZONE, settz(), ... ?
by Chris Torek Dec. 11, 1986

Dec. 11, 1986

I agree with kre: The original design was wonderful. The major problem was that it was not---quite---compatible with 4BSD and with SysV. Yet the incompatibilities were in areas that everyone agrees were weak, and, moreover, in areas that were mutually incompatible anyway! Any new standard *must* break some code. Let it break code that was acknowledged insufficent, and by replacing it with code that has been tested and found satisfactory. Chris

1 0

comments of proposals
by seismo!nbires!vianet!devine Dec. 11, 1986

Dec. 11, 1986

Excuse the delay in responding to some of the issues, things have been rather hectic. Some mail may have been dropped locally (sorry if I'm talking about something that is solved). 1. Ctime functions. I favor the following small collection: char* ctime(time_t) struct tm* localtime(time_t) struct tm* gmtime(time_t) char* asctime(struct tm*) time_t mktime(struct tm*) int settz(char*) /* set up a user selectable timezone */ int strftime(char*, int, char*, struct tm*) These supply the time conversion capabilities needed. This set can be extended with internationalization functions that parallel ctime() and asctime(). "Maybe" category: int strfastime(char*, int, char*, struct tm*) int systz() -- 1) set up the system default timezone -- 2) not needed if a certain string passed -- to settz() tells it to use the local -- system timezone (settz("LOCAL") ? ) -- (internationalization problems?) int yearlength(int, int) [see comment below] Not included are: long timezone; /* yuck */ int daylight; /* yuck */ int dysize(int) [see comment below] char* tzname[2] /* too limited */ timezone() zonetime() -- I haven't seen the definition of this HP's nl_*() functions I have submitted a group of functions to Rich Salz for posting to mod.sources that, while not yet complete, do deal with the many different country-dependent changes to calendars. It is a function that takes a Christian era year and a country id and returns the number of days in that year for that country. yearlength() is more thorough that dysize(). The function's current drawbacks are that some of the dates are a bit shaky (I have on order a book from the Vatican that I was told is the definitive source) and not all countries from all years are represented. 2. Modification to 'struct tm'. I agree that 'struct tm' should be modified to adequately describe a certain time. So, three fields should be added: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; The elements 'tm_tzdiff' and 'tm_dstdiff' are for informational and, more importantly, for the mktime() function so that it can correctly convert any 'struct tm' into a time_t. Both are set to the time_t equivalent of zero for the structure filled in by gmtime(). 'tm_tzdiff' holds the difference in seconds (or whatever time_t is defined to hold) for the timezone difference from UTC. 'tm_dstdiff' is the same but for daylight saving time (is there a better name that describes the seasonal clock changes? [see note]). The 'tm_tzname' is the name of the timezone used when filling in the structure. Its role is informational and also serves as a guide to going from 'struct tm' to a time_t. [note: the city of Denver looked at the possibility of going to a clock change for the high-pollution period of December-February where temperature inversion and reduced auto efficiency in cold weather result in very high carbon monoxide levels. Changing the clocks so that Denver would, in effect, be in Central Time instead of Mountain Time would help reduce the levels because the sunlight would alleviate some. Consider this a LST - lung saving time :-)] 3. TZ and TIMEZONE For current programs that use it, TZ must be kept as is. The new variable TIMEZONE should be defined to handle the wide range of possible and different timezones that TZ can't handle. Its format could be open or tightly defined; I haven't given this enough thought. Bob Devine [ in case you're interested in what caused the havoc around here, no, the entire place is not shutting down as happened to me at UNISYS (nee Burroughs). ViaNetix just got sold to a company whose name I can't yet give out and we changed what machine is known as 'vianet'.]

1 0

Re: timezone proposals for P1003
by seismo!zotz.cs.utexas.edu!jsq Dec. 9, 1986

Dec. 9, 1986

The current state of timezones in P1003 is that there is a proposal, P.55, which is one step past the prevrious form, RFC.001. You've seen the text for oboth on mod.std.unix. I haven't yet attempted to get P.55 adopted as part of the actual document. This is because a) I'm stilll waiting for HP to produce their long-awaited alternative proposal and b) I'm stuck in L.A. and won't be at the meeting this week. Simplicity has been stresssed in discussing timezones in P1003 meetins. Members have seen your (and others') previous omments. I expect to get the committee to consider actually adopting P.55 at the next meeting in March. There has been no noticable objection from the AT&T reps or anyone, really, thus far, except that HP want their proposal instead (though no one has seen it yet). I would strongly recommend that any needed changes to P.55 be gotten to me before March and any points I don't know about tha should be raised in discussion be relayed.

1 0