Date: Can it be specific to a shell??

[John Chambers]

In article <322 at bilver.UUCP>, bill at bilver.UUCP (Bill Vermillion) writes:
> In article <1138 at virtech.UUCP> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
> ->In article <72074 at yale-celray.yale.UUCP>, zador-anthony at 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