Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ogccse!blake!milton!uw-beaver!mit-eddie!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.questions Subject: Re: Date: Can it be specific to a shell?? Message-ID: <17@minya.UUCP> Date: 25 Sep 89 23:07:14 GMT References: <72074@yale-celray.yale.UUCP> <1138@virtech.UUCP> <322@bilver.UUCP> Distribution: usa Organization: home Lines: 76 In article <322@bilver.UUCP>, bill@bilver.UUCP (Bill Vermillion) writes: > In article <1138@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > ->In article <72074@yale-celray.yale.UUCP>, zador-anthony@CS.YALE.EDU (anthony zador) writes: > ->> > ->> How does the UNIX date command know the date? > ->> Is there some file that is updated? > ->Nope. > ->> Must date be the same to all shells on a given machine, > ->Yup. > Believe that answer should be nope. > How about Yup. > That is the date is displable in several different time zones, but the machine > time stays the same - UCT (nee GMT). > > This machines variable for TZ is set as EST5EDT. All I did was spawn a > sub-shell and do TZ=CST6CDT; export TZ. > > Then I did a date, and the machine thought I was in Texas (or somewhere in the > Central zone). > It realy has to be this way, as you want local time displayed in the time zone > of the caller. It makes sense to set TZ variables in the shell if you have > callers spanning time zones. The trouble with this is that you've assumed rationality on the part of system builders, as well as consistency in all releases of Unix. Neither is true. Sys/V generally uses the TZ environment variable, which is a fairly rational approach to handling the problem. It still doesn't handle the variety of rules for changing between standard and dayligh-saving, but then, who knows how to do that in a multi-timezone/multi-national system? Unfortunately, Berkeley systems haven't generally adopted this approach. BSD systems still store the timezone in the kernel, and many programs use the kernel's idea of the timezone regardless of anything in the user's environment. Thus, if you have a Sun, you tend to find that everything is Pacific time until you configure the kernel to know your timezone. This can be done via adb, but it must be done. And I know from experience that much Sun software gives rather undesirable results when you are in a different timezone than the kernel. It's even more fun when you use systems that have tried to merge BSD and ATT systems (which includes Sun, and a lot of others). You find that some of the library programs use the TZ environment variable, while others ask the kernel. I worked recently on some Sequent machines, which support two "universes" with different libraries. Two users on the same machine could quite easily get different timestamps for the same file, depending on which universe they logged into, even with apparently the same search paths and environments and shells and all. It could be worse. Most VMS systems still keep their system clock in local time, and when networked across timezones, they have lots of confusion trying to figure out what time it is. You can get some very interesting misbehavior from such programs as "make" in such cases, when a file you just saved has a timestamp off by an hour. (It's especially fun to see a file get created in the future. ;-) I also recently tried using some network-management software from Bridge (now 3Com) that used ASCII timestamps, local time, and didn't include any indication of timezone. When we tried using it to manage systems scattered across several timezones, its behavior was quite entertaining. After a lot of good laughs, we threw up our hands and went on to something else. They even run on Unix systems (Suns, actually), but they haven't learned. You'd think by now that system programmers would understand why timestamps should be in UT/UCT/GMT, but I wouldn't go betting any large budgets on it. I also wouldn't make any assumptions about the portability of code that uses anything but the binary Unix time() value. And even that is frequently off by multiples of an hour in various machines on a network. -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying