...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.