- tz - lists.iana.org

Default timezone
by seismo!cuuxb!dlm Dec. 18, 1986

Dec. 18, 1986

The issue of what time zone to use if the TZ variable is not set should be thought out a bit more. ATT has decided to use a "default" of GMT if no TZ is set or if it is NULL ( "TZ=" ). Our reasoning is that in the majority of cases this is an error by the system administrator in setting or exporting the TZ variable and it is necessary for someone to notice the error. As it stands most developers/porters set the TZ to their local time zone (who is it that uses PST?!) and then never notice that their product has problems. Using wall clock as default merely propogates this development problem and results in products having problems when they are used in other environments. The use of wall clock as the "default" ought to be a concious choice by a programmer and GMT ought to be the default whenever a time routine can't decide what timezone to use.

2 1

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

Conversation with Ron Tolley
by ado Dec. 9, 1986

Dec. 9, 1986

Ron Tolley of Hewlett-Packard called Friday. I'd like to relay a couple of points Ron made (points which may or may not reflect official corporate policy of H-P, blah blah blah), add some notes of my own (notes which may or may not reflect official policy of the National Institutes of Health, blah blah blah), and ask for comments. 1. Setting up "new" time zone handling software to deal with environment variables such as TZ=US/Eastern may make for problems when running "old" executables that expect the TZ environment variable to be of the form TZ=EST5EDT where, depending on the quality of an implementation, "problems" here can range anywhere from getting core dumps to getting incorrect results. As others have noted, staying strictly with the current System V TZ=<standard abbreviation><offset from GMT><daylight abbreviation> system can't work--for example, with TZ=EST5EDT there'd be no way to tell whether a user wanted Canadian or US Daylight Saving Time rules applied. The possibilities I see: a. Continue to demand that the TZ environment variable be of the form TZ=<standard abbreviation><offset from GMT><daylight abbreviation> (a possibility I'd dislike). b. Set things up so that, for example TZ=EST5EDT asks for US rules to be used while TZ=Est5Edt asks for Canadian rules to be used--although either of the above would "EDT" to be used in the output of date(1) and such. This will, of course, meet with the disapproval of those who think case sensitivity in UNIX is a bad thing. :-) c. Set things up so that the TZ environment variable is of the form TZ=EST5EDT and so that a new environment variable such as TZTYPE=Canada tells the type of time zone rule to be applied. d. Set things up so that instead of setting TZ=US/Eastern you instead use some new environment variable--for example ZONE=US/Eastern With this approach, old executables don't get confused by zone information that's in a new format since the new-format information is put in a place that the old executables don't look. The disadvantage of this approach is that old executables don't get *any* information about what the user wants. (Implementation point: new software would presumably first look for "ZONE" in the environment and then fall back on "TZ" if "ZONE" was absent from the environment.) e. Throw caution to the wind and set things up so that TZ=US/Eastern is used (a possibility that Ron Tolley dislikes). My current leaning would be toward possibility 'd' above--with careful documentation of tzset's habit of looking for ZONE and then TZ. 2. Ron noted that H-P's approach to getting guaranteed local wall clock time is to use the 4.?BSD "gettimeofday" call. This contrasts with approach demanding that local wall clock time be returned by "localtime" if there's no TZ environment variable. The H-P approach does have a real backward-compatability advantage. If, in trying to ensure that I'm going to get wall clock time, I write code that zaps TZ from the environment and then does tzset(); and localtime(); calls, the code will happily compile and run on existing System V systems-- and may give wrong results. If, on the other hand, I write code that calls gettimeofday(); the code won't compile at all on existing System V systems. The bad news is that I won't get any results at all; the good news is that I won't get wrong results. One possibility I'd see: drop the demand that local wall clock time be used if TZ is absent from the environment, and add a function such as walltime() that returns "the best available approximation of local wall clock time regardless of the setting of the TZ environment variable." It would be a close analog of "gmtime". --ado

2 1

Re: walltime vs localtzset
by ado Dec. 8, 1986

Dec. 8, 1986

Guy Harris's point on localtzset being much easier to implement than walltime is very well taken. Of course, the real name will need to be different to avoid conflicts between localtime and localtzset on systems with only six characters worth of external identifiers. Maybe tzsetlocal? --ado

1 0

Re: Conversation with Ron Tolley
by seismo!sun!guy Dec. 8, 1986

Dec. 8, 1986

...instead use some new environment variable--for example ZONE=US/Eastern With this approach, old executables don't get confused by zone information that's in a new format since the new-format information is put in a place that the old executables don't look. The disadvantage of this approach is that old executables don't get *any* information about what the user wants. Old executables can't necessarily give the user what they want anyway; for example, they won't give people in South Australia what they presumably want. (Implementation point: new software would presumably first look for "ZONE" in the environment and then fall back on "TZ" if "ZONE" was absent from the environment.) If "TZ" is to be parsed, rather than used as a file name, you'd have to indicate which rules are used; presumably, you can use the US rules (i.e., hardcode the current rules, or the current rules as modified for the 1987 change), since that leaves people no worse off than they are now. Also, I'd vote to change "ZONE" to "TIMEZONE"; environment variables don't need to have short names, and you might as well give them a name that more precisely explains what they do. One minor nuisance with this is that a program would have to smash both "ZONE" and "TZ" in order to guarantee that they'll get the CPU's local time (we ignore the possibility of the CPU being in one time zone and the modems, or the bulk of the terminals, being in another :-)). If, on the other hand, I write code that calls gettimeofday(); the code won't compile at all on existing System V systems. Did they really mean programs call "gettimeofday" directly? All "gettimeofday" returns is the current UNIX clock time (which is in GMT/UTC) and, optionally, a structure indicating the current offset from GMT and rule set to be used to handle DST. As such, you'd have to duplicate much of "localtime" to use this data, which seems excessive, and it would still suffer from the disadvantages of the 4BSD scheme. One possibility I'd see: drop the demand that local wall clock time be used if TZ is absent from the environment, No! It is difficult, if not impossible, to guarantee that TZ will be properly set in the environment. Forcing every use to stick something in their ".profile" or ".login" is gross, and also doesn't work if your login shell is neither "/bin/sh" nor "/bin/csh". This would screw not only login "shells" like "/usr/lib/uucp/uucico" (although it doesn't *want* TZ to be set, it always wants the machine's local time) but also things like office automation systems and other applications that put you into a special environment when you log in. Those applications don't necessarily know anything about shell scripts, so they can't just scan ".profile" or "/etc/profile" or whatever. and add a function such as walltime() that returns "the best available approximation of local wall clock time regardless of the setting of the TZ environment variable." It would be a close analog of "gmtime". This is a bit complicated; I'd prefer something like localtzset() which acts like "tzset()" except that it looks neither at "TZ" nor at "TIMEZONE" but forcibly sets things up for the "official" local time zone of the machine. That minimizes the changes needed to fix things like "uucico". This also obviates the need for an application to smash both "TZ" and "TIMEZONE" if it wants local time; "localtzset()" would do whatever is necessary, and the application wouldn't have to know what was necessary. The rules would be: "localtzset()" would forcibly cause subsequent conversions to use local time. "tzset()", called by "localtime" and "mktime" would first check if "TIMEZONE" was present in the environment; if so, it would use that. Otherwise, it would check if "TZ" was present in the environment; if so, it would use that. Otherwise, it would use local time. "TZ" looks like it would be a wart if it were put into the P1003 standard (as opposed to a UNIX manual page, where people are used to seeing horribly warty specifications). However, if you leave it out, it would either have to say that if "TIMEZONE" isn't set, it uses local time (if possible), meaning that "TZ" can't affect its behavior, or would have to say that the behavior if "TIMEZONE" is not set is implementation-dependent, meaning that the current unacceptable S5 behavior (use Eastern Standard Time if "TZ" isn't set) would be permitted.

1 0

Re: Conversation with Ron Tolley
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 8, 1986

Dec. 8, 1986

I also think going to a new environment variable such as ZONE (I'd rather see it called TIMEZONE) is the best choice; there's nothing to prevent the system from defining both TZ (for upward compatbility) and TIMEZONE (for new software which checks for it first.) I think that any standard that requires that TZ do anything may be a mistake; if the standard says that a missing TZ means something, then any upward compatible future standard based on another variable will lose big. It would be best if comments about what to do if TZ is missing were made in such a way that they are just a fallback, not a way for a program to get a guaranteed behavior. Mark

1 0

Re: timezone proposals for P1003
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 8, 1986

Dec. 8, 1986

Just a brief note on history; Robert points out, quite correctly, that the 4BSD timezone() function, use of ftime, and so on, all date back to V7. I just wanted to point out that the System V convention of the external variables "timezone" and "daylight" date back to V6, essentially untouched. V6 did not have ftime, the TZ environment variable (or environments at all), nor tzset. I'm not sure how it knew the local time zone; I don't believe the date command, or any other piece of software, produced a time zone name, but I think timezone and daylight were statically compiled into libc, and you had to relink the system if you installed it anywhere except the USA Eastern zone. Thus, the conflict between the timezone external integer, and the timezone function, seems to have been introduced by Bell Labs 127 group, sometime between V6 and V7. This conflict will make life interesting for any implementations striving for upward compatiblity with both systems. As far as I am able to determine, neither X3J11 nor POSIX requires either, but of course the SVID requires the integer. This suggests that it would be nice if Berkeley phased out the function. Mark

2 1

timezone proposals for P1003
by Robert Elz Dec. 7, 1986

Dec. 7, 1986

I think things are getting way too complicated. All P1003 needs (and all it should have) is a spec of the interface that programs should have to time conversions. And that ought to be the minimally sufficient set, not everything that might be useful to someone, someday. nb: this is not a reference to the "nl" procedures, some kind of standard for that is clearly needed, or posix will be tied to English (or what passes for English in the US) forever. What I am referring to is the file formats, etc, which clearly don't need to be in any standard. What's more, there should not even be an implication that there is a file with this kind of information in it somewhere. That's none of the interface's business, its an implementation issue. On a host with good shared libraries, continuing to compile the needed information into libc.a is a perfectly reasonable strategy. Another would be to make a RPC call to some server to obtain the information. P1003 has no business outlawing any of that. Furthermore, there is NO need for P1003 to contain everything that's in Sys V. Not even AT&T believe that. Unless some detail of Sys V is needed for the interface, then it should not be there (this does not make P1003 incompatible with Sys V, it just makes Sys V a superset, offering more than P1003 requires). In this area Sys V's "timezone" and "daylight" variables fall. They're next to useless, a static variable in the Sys V sense cannot possibly contain useful information. if they were allowed to change on each call to localtime, to reflect the results of that call they might be useful, but without that they're useless. I've never yet seen an application with any excuse for using "daylight". The information purported to be supplied in "timezone" does have its uses, but the static variable can't contain that. What do you think should be in "timezone" in South Australia, where the standard zone is currently 9:30 ahead of GMT, but which is going to change to 10:00 ahead of GMT on Mar 15 (I think) next year? Should "timezone" be -36000 or -34200? Remember that there will be application programs running at the instant this switch is made (02:00 standard time, on that morning), so any solution that involves changing the value of timezone (a variable that isn't altered after its set by tzset()) can't be correct. For "timezone" in the Sys V sense to be meaningful at all, one of those two numbers (or perhaps some other) must be chosen, and retained forever. The v7 (inherited by bsd) "timezone()" function is a joke. It can't even come close to doing what it claims. It has to go. Incidentally, all the "bsd" columns here should be labelled "v7". Bsd has made no changes to any of this, at all, ever. All that ever changed in this area was some of the implementation details. Also, there's no good reason for the standard to constrain the syntax of the TZ environment variable in any way at all. If some implementation finds that it can extract useful information from the letters, digits, colons, etc, found in the value of that variable, then fine. That is perfectly consistent with an unconstrained format. But, as soon as you introduce any unnecessary rules, things start breaking down. As an example, last year, the TZ values (in the standard Sys V sense) for NSW and Victoria (in Australia) would have been identical. Both EST-10EST. (That is, both NSW and Vic have "EST" as their timezone abbreviation in standard time (Eastern Standard Time, as in the US), they're both 10 hours ahead of GMT, they both have daylight saving, and both use EST as the abbreviation for the zone name when daylight saving is used (Eastern Summer Time). But last year (for a week) their daylight saving rules were different. The Sys V format simply cannot cope with this kind of thing. (I think they were different last October, if not then, they were in 1982 for 3 weeks in March). The unconstrained form can handle this. Easily. So, please, in any submissions to P1003 (on this point, and any others) please emphasise simplicity. Anything that's not demonstrably both essential, and workable, should be omitted. What MUST be there is some way for a program to get access to localtime in the absense of a TZ variable. There are security issues here, TZ is a user alterable variable, and cannot be depended upon. This is the one thing that is going to have to be added to Sys V. Add that, and current Sys V should be P1003 compliant (ignoring language issues for now). BSD is going to need more changes, but that's not a problem, changing BSD is easy... Personally, I don't much like the idea of doing that by having the TZ variable changed by the application. That would be workable, certainly (assuming that there was some guaranteed value it could be set to to obtain local time) but it seems more complex than is needed, and somehow just not nearly as clean as settz((char *)0) in ado's current code. Also, given that this is absolutely essential (and this is THE defect in the Sys V current localtime interface incidentally - that it has one set of daylight saving rules compiled in is a mere implementation foible -- oh yes, the "only hours" in the TZ variable is another defect) its a good idea to make the default be that if there's no TZ variable, then localtime is obtained. That means that users who only want localtime anyway need one less environment variable slowing down all their processes - the environment should be used for user configuration, not system configuration. I'm not much thrilled with tzname[2] either. To be truly Sys V compat, that also needs to be statically set at the tzset() - a Sys V process can now grab pointers to the strings in tzname after tzset() and use those forever after. There's no way to be compatible with that, and at the same time handle a location with more than 2 zone names. Again, South Australia next year, it will have CST, EST and EST all in the same year. (That two of these are the same is a coincidence, assume for now that Australia used the US naming convention, then the names would be CDT EST and EDT). I gather that the current idea is to make tzname[] be a placeholder for a result of localtime(), changing after each call. I'm not sure what the "other" size of tzname[] is supposed to contain though. Ie: if I reference tzname[!tp->tm_isdst] what do I get? Is it always defined? How? Looks impossible to me (that is, to be defined to something sensible). This looks to be another area where the desire for Sys V compatibility is going wild. If its *wrong* in Sys V than POSIX is the chance to fix it. Possibly the last chance, forever. Perpetuating an error just for some compatibility seems like a bad idea. A better idea might be to add a "char *tm_zone" to "struct tm" and shove the zone name in there. That at least makes it quite clear that the zone name is a property of the specific time, and that a zone name without an associated time is a meaningless concept. Yes, I know this is going to break some programs, and that's a pity, but I think its necessary. Robert Elz seismo!munnari!kre ps: I have added a cc to John Quarterman, who I guess is as close as anyone to being my representative on P1003, given that I'm a usenix member... John, this is in response to some discussions over the HP proposals and other replated issues. elsie!ado can fill you in on what's been going on I think. There's a mailing list at elsie for tz discussions.

1 0

a letter from hpfcdg!rgt
by Arthur David Olson Dec. 4, 1986

Dec. 4, 1986

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

1 0

Another round from Hewlett-Packard
by Arthur David Olson Nov. 27, 1986

Nov. 27, 1986

Ron Tolley has sent me revisions of the Hewlett-Packard ctime and tzfile manual pages; anyone interested in receiving a copy of the revisions should let me know. --ado

1 0

seismo!elsie!tz ; new versions of time zone stuff
by ado Nov. 25, 1986

Nov. 25, 1986

Now that we've moved from 4.1BSD to 4.3BSD here at elsie, I've set things up so that mail sent to seismo!elsie!tz will go to folks who've expressed an interest in time zone matters. The address seismo!elsie!tz-requests may be used for administrative matters. Currently on the list: ado(a)elsie.UUCP chris(a)umcp-cs.UUCP mark(a)cbosgd.ATT.COM kre(a)munnari.OZ dlm(a)cuuxb.ATT.COM devine(a)vianet.UUCP bob(a)anvil.UUCP rgt(a)hpfcdg.UUCP guy(a)sun.UUCP If you want to be removed from the list, or know of someone to add to the list, let me know. ******************************************************************************* And now the real news: new versions of the time zone compiler, the ctime et al. library, and the time zone data are available. Guy Harris provided the bulk of the ideas and work that went into the new versions, but should be held innocent of any blame for errors since I've tinkered with Guy's work (in part to try for more compatibility with System V and the work of rgt(a)hpfcdg.UUCP, who's the time zone person at Hewlett-Packard). The important differences: * There's a new format for the binary versions of time zone information files, designed to allow the files to be used by both big-endian and little-endian machines in shared file environments. * Up to now, a call of "localtime" caused the global variable "tz_abbr" to be set to point to the time zone abbreviation that was appropriate for use with the converted time. Now, "localtime" stores the pointer in tzname[*localtime()->tm_isdt], which is where System V programs have expected to find it. * Also for System V compatability, the function tzset is provided-- it just does a settz(NULL). * And the compiler is now a bit smarter--if you feed it something like: # Zone NAME GMTOFF RULE/SAVE FORMAT [UNTIL] Zone US/Hawaii -10:30 USA H%sT 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 1 2:00 -10:30 USA H%sT 1947 Jun 8 2:00 -10:00 - HST it will apply the normal USA rules in Hawaii until April 30, 1933, then do Hawaii's day's worth of daylight saving, then switch back to standard rules until June 8, 1947, and finally go on to permanent standard time thereafter. This does a lot to shorten (if not simplify) the compiler's input files. If you'd like copies of the new versions, let me know. Once the new stuff has made the rounds, I'm hoping to get the benefit of other perspectives on what more can be done to bring this work, Hewlett-Packard's work, System V, and BSD closer together. --ado

1 0