Date: Can it be specific to a shell??

[Guy Harris]

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

Arthur Olson and the rest of the Timezone Cabal do; it's a solved
problem.  Read the rules from a file, whose name is constructed from the
value of TZ....

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

4.3-tahoe uses the Arthur Olson code, and programs built under 4.3-tahoe
get the timezone from the TZ environment variable, if set, or from the
"default" time zone file (the one with the link to it named
"localtime"), if TZ is not set.  No programs built under 4.3-tahoe
should still be bothering to get the time zone stuff from the kernel;
the only ones that should are ones that haven't been recompiled yet.

>Thus, if you have a Sun, you tend to find that everything is Pacific
>time until you configure the kernel to know your timezone.

Assuming you're not running SunOS 4.0 or later, which also uses the
Arthur Olson code; all programs built under SunOS 4.0 should use TZ if
set, or use the "default" file if not.

>This can be done via adb,

Or by reconfiguring the kernel, which may be a bit less painful.  (In
SunOS 4.x, it's done automatically by "tzsetup", run at boot time, which
looks at the default time zone file's data and tries to pick the value
for the kernel that most closely matches it; this is done for the
benefit of old binaries.)

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

This is definitely a pain, but it's no longer true in SunOS 4.0, as
noted.  With any luck, other vendors will pick the Olson code up as
well, and have all environments handle time zones in the same way; one
vendor that has picked up the Olson code is AT&T, for S5R4....