- tz - lists.iana.org

Re: Default timezone
by seismo!sun!guy Dec. 20, 1986

Dec. 20, 1986

While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. Not really. I tested Arthur Olson's code, which doesn't read "/etc/TIMEZONE" but *does* read a file of rules, with a program that just converted the current time using "ctime". The difference in time was negligible. It probably took more time to load the test program(s) than it took to read the files - and this was a version that read files that were written with a machine-independent byte order; it wasn't just doing one big "read". Even using Sun XDR, it wasn't a major difference. (Also, remember that a program won't read "/etc/timezone", or the setup files, *every* time it calls "ctime"; once is enough. Yes, this means you have to restart long-running programs if the rules change, but that shouldn't happen too frequently.) This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Unfortunately, it's also incomplete, unless you extend "ftime" to return a table of DST on/off times. Recompiling every program that uses "ctime" because the U.S. Congress extended DST is a pain; it's worse in countries that seem to change the rules on a yearly basis....

1 0

Re: Default timezone
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 19, 1986

Dec. 19, 1986

While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Mark

1 0

Re: Default timezone
by seismo!sun!guy Dec. 18, 1986

Dec. 18, 1986

> From: seismo!cuuxb!dlm (Dennis L. Mumaugh) > Subject: Default timezone > 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. What "problems" does setting TZ to the local time zone (which *IS* PST here where we do *our* development) disguise, and why does defaulting to GMT if TZ is missing or empty reveal them? > Using wall clock as default merely propogates this development > problem and results in products having problems when they are > used in other environments. So does setting TZ in "/etc/init". The only way to flush these problems out before the product is released is to *deliberately* run it with timezones other than the developers' zone. > From: seismo!cuuxb!dlm (Dennis L. Mumaugh) > Subject: Re: Parsing /etc/TIMEZONE > I do like the idea of a single place for establishing the TZ for > a system. It makes it very easy for new administrators. Olson's scheme has this, as well; you just use the "-l" flag when running "tic". It causes a link name "localtime" to be made to the time zone specified as the argument to "-l". > Another problem with a routine to read and parse /etc/TIMEZONE is > what does one do for non-ATT shells (c shell and others) the > setting of TZ in the environment differs. That's why having > /etc/init set things up is good. That guarentees a "standard > environment". It is true someone could diddle with it, but I am > more concerned with naive users than others. You're going to need a routine to read and parse "/etc/TIMEZONE" anyway. "uucico" will have to use it; it does NOT want to use "TZ" to indicate what the local time zone is, precisely *because* somebody could diddle with it. > From: Robert Elz <seismo!munnari!kre> > Subject: Re: Default timezone > Date: Wed, 17 Dec 86 11:09:09 cst > From: cuuxb!dlm (Dennis L. Mumaugh) > Message-ID: <8612171709.AA08584@cuuxb> > The issue here really, is how does a programmer exercise his > "conscious choice" to get wall clock time? > If you wanted to define /etc/TIMEZONE or something as a > file containing the right TZ string, so that programs that > need wall clock time would be required to go read (and parse) > that file, then that would be a solution. But you had better > be prepared to define the format and name of that file, > and stick to it forever more. You should also be prepared > to go and find all the standard processes that need this > (like uucico, and others) and insert the relevant code. Actually, any scheme would require you to find all the processes that understand this, and insert some code to ensure that the machine's time zone is used. > Personally, I prefer a slightly simpler interface. That > doesn't preclude putting the information in a file, of > whatever format you prefer, but it should be the time > functions that read the file, not the user's code. Absolutely. This could be done in the S5R3.1 scheme, by providing a function to read "/etc/TIMEZONE". You could even call this function "settz()" (see below). > This also allows for more implementor flexibility, she > has lots of choices she can make as to how to obtain > the local wallclock time - from a simple ascii file, > from a precompiled binary file, from a network information > server, from the kernel via a system call, and I assume > lots of others. I can even imagine processors where local > time might be available as an instruction in the instruction > set (I can imagine such processors because we have one...) Do you mean "local wallclock time" or "local conversion rules"? With current UNIX interfaces, and with all the proposals that have popped up so far, all you could do is get the latter and use them to convert the result of "time()" to local wallclock time. > Certainly having local wall clock time be the default > when TZ is not set is a very sensible way to do things, > as it means that the system administrator doesn't need > to set up TZ for every process in the system, The S5R3.1 scheme does handle this, by having "init" put the time zone in its environment. > Most of the people on this list seem to feel that the > right way for a program to choose wallclock time explicitly, > is to putenv() TZ to a null value. Personally, I still think > settz() is a cleaner interface. Actually, "settz()" could be implemented in the S5R3.1 scheme. Assume that the time conversion code takes some string and uses it to set up the conversion rules (details deliberately left unspecified). "tzset" would use the value of 'getenv("TZ")' for this string. "settz" would do the following: if its argument is a null pointer, read "/etc/TIMEZONE" and use the string located therein; if its argument is a pointer to a null string, use GMT; otherwise, use its argument as the string in question. There is one issue here; should a process only be able to affect how its UNIX time <-> local time conversions are done, or should it also be able to affect any children it spawns? The former is effected by "settz"; as it stands, the later requires you to change TZ, either by eliminating it, nulling it out, or setting it from "/etc/TIMEZONE". "uucico" would probably want to affect its children; some other program might not. I do have another question; are we discussing UNIX or POSIX here? If the latter, should POSIX require that anything be supported other than local machine time? It may be convenient to permit users to specify other time zones, but user convenience is somewhat outside the scope of 1003.1, at least. POSIX should not *preclude* a user overriding the default time zone, and as such must provide a way for a process to override the user's override and get the default timezone; it probably must also provide a way to force its children to use the default time zone, as well. For this, all you need is a function that says "set time zone to the default"; the full generality of "settz" isn't necessary. You could have POSIX just define the behavior of "settz(char *)NULL)" and leave the rest up to the implementation. POSIX must also require that an application must, by default, get some "reasonable" time zone information, which would either be the system default time zone or, if supported, a user-specified time zone. It must do so in such a way that no application need explicitly set up anything (such as snarfing the right value of TZ from "/etc/TIMEZONE") in order to get this information, and in such a way that no application need be run in a special environment (i.e., saying "the way you set it is to put it in "/etc/profile" is out). Olson's scheme provides most of what is needed from the POSIX standpoint. "settz" could be added to the S5R3.1 scheme, and it would be equivalent (from the program's standpoint) to Olson's scheme. Both Olson's scheme, and the S5R3.1 scheme with "settz" added, would provide a way for a program to explicitly choose a particular time zone (and it would work in the same fashion in both schemes), and would use the value of TZ if one was provided. Both schemes make it simple for an administrator to set the default timezone; in Olson's scheme, you just run "zic" with the "-l" flag specifying the default zone, or make the link yourself, and in the S5R3.1 scheme you just set the "/etc/TIMEZONE" file. Neither scheme directly addresses the question of "how do you teach your children about the time zone you selected"? One way to do this would be to use "putenv"; however, that exposes various implementation details that really should not be exposed. Perhaps there should be a function like "settz" that propagates that change to children.

1 0

Re: Parsing /etc/TIMEZONE
by seismo!cuuxb!dlm Dec. 18, 1986

Dec. 18, 1986

Yes, it is true that my parse routine does use standard IO. Also it is simple minded about "shell". It doesn't know about quoting or shell escapes: thus the new expanded TZ will break as there is a semi-colon in the TZ string. Oh well, what do you want for free? BTW, the init parser for SystemV Release 3.1 is not very smart either. I do like the idea of a single place for establishing the TZ for a system. It makes it very easy for new administrators. Another problem with a routine to read and parse /etc/TIMEZONE is what does one do for non-ATT shells (c shell and others) the setting of TZ in the environment differs. That's why having /etc/init set things up is good. That guarentees a "standard environment". It is true someone could diddle with it, but I am more concerned with naive users than others.

1 0

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