- tz - lists.iana.org

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

Dec. 12, 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. 10, 1986

Dec. 10, 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