Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!seismo!brl-adm!adm!lcc.rich-wiz@CS.UCLA.EDU From: lcc.rich-wiz@CS.UCLA.EDU Newsgroups: comp.unix.wizards Subject: Re: Yet Another Solution to the ctime problem Message-ID: <6686@brl-adm.ARPA> Date: Sat, 4-Apr-87 09:23:29 EST Article-I.D.: brl-adm.6686 Posted: Sat Apr 4 09:23:29 1987 Date-Received: Sun, 5-Apr-87 10:36:15 EST Sender: news@brl-adm.ARPA Lines: 50 > From: Root Boy Jim > Artificially setting the time off by an hour for three > weeks is for the birds. (This is what several vendors > are recommending.) If I wanted to set my system clock > periodically to account for DST, I'd run VMS. > In the meantime, the vendors are correct. This is an administrative > and political problem, not a technical one. Either put up with the > difference, or run on GMT like the military and scientific types > who *really care* what time it is. The vendors are not correct if someone tries running a "make" in the one hour after the time is set back on April 26. (Run a make just before the change; then edit a .c file right after the change; a following make will screw up. This gets especially bad if you touch a lot of files and don't notice that a few of them didn't recompile.) A better solution (for temporarily fixing the problem until the next release), at least on System V systems, has been suggest by AT&T for binary sites: change the TZ environment variable from, for example, TZ=PST8PDT to TZ=PDT7. Using the short form of TZ tells ctime() that it should ignore its own daylight savings rules. Changing the number from 8 to 7 and using PDT in the first field will then simulate being on year round daylight savings time. Since most users don't set TZ in their .profile/.cshrc/.whatever, changing the default TZ and rebooting will be enough to get it into everyone's environment. The problem with this is that dates before April 5 will also be displayed as if DST had been in effect at the time. I like the flexibility that TZ gives. It allows for different users on the same machine (or distributed system) to be in different timezones. Its biggest drawbacks are that it only allows timezones which are an integral number of hours away from GMT (they should have used minutes or hours:minutes, not just hours) and that your only choices are U.S. daylight savings rules or no DST at all. Even so, it is a lot better than putting the timezone in the kernel, as with BSD. I haven't seen Arthur Olson's code, but it would be a good idea for it to accept an environment variable which specifies an alternate name for the file with the DST data. It would also be good for it to recognise Sys V's "TZ" to override the kernel's idea of timezone. This would then seem to be the best of all worlds. Richard M. Mathews Locus Computing Corporation lcc.richard@LOCUS.UCLA.EDU lcc.richard@UCLA-CS {ihnp4,trwrb}!lcc!richard {randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard