TZ in Other Countries

[Guy Harris]

> NOTE:
> 	The following refers to AT&T's UNIX(tm).  It may or may not also
> apply to Berkeley versions.
> 
> 	I would like to know how UNIX installations outside of the U.S.A.
> manage Day Light Savings  in their ctime(3C) routines.  There  is code in
> tzset() (which  is called by all of the ctime routines) to move the clock
> ahead (back) at the appropriate time of the year.
> 	I know that some other countries  move their clocks  at different
> times of the year  from us....

This is one thing that 4.2 has worked on; AT&T should pick it up (preferably
intact, unless they've got one that's *significantly* better - no reason
to be different from 4.2 just for the sake of being different).  Instead of
a binary "daylight savings time is in use here" flag, there's a "type of
daylight savings time" flag.  A value of 0 means no DST, and a non-zero
value selects one of several tables indicating the start and end of DST.

> Also, some  countries have time  zones which are not in hour  jumps, but
> increments of  15 or 30 minutes.

AT&T should put in a trivial fix to this; they should permit the time zone
offset to be of the form "hours:minutes", such as

	QST7:30QDT

where Quahog Standard Time is 7 hours 30 minutes away from GMT.

While they're at it, they should provide a way of getting the time zone
other than from the TZ environment variable, because

1) It's a royal pain in the *ss to make sure every program has the TZ
variable set; putting in /etc/profile is *not* sufficient, as not all
login shells are Bourne shells that read /etc/profile!  Furthermore,
in a vanilla S3 system (and, I think, a vanilla S5 system), setting
the environment of the "getty" command doesn't help because "login"
blows away its environment and replaces it with a freshly-crafted one
that doesn't have TZ (or TERM, thus forcing you to set TERM every time
you log in, even if the system knows that you're logging in from the VT100
at your desk).

2) You can fool programs like "uucp" into making calls to other systems
outside of the hours specified in the L.sys file by faking the time zone
offset.  (Thanks to Mark Horton for poiinting this one out.)

Getting it from the OS, as was done in V7, would be nice; either it could
be set at sysgen time, or by a system call or just a command which writes on
/unix and /dev/kmem.  If TZ is present, it'll use that, otherwise it'll use
the value from the OS (rather than the hardcoded EST5EDT that it currently
uses if TZ is missing).  Programs which don't want TZ faked out can do
a "putenv" to stomp on TZ (making it a null string, say), and the "ctime"
routines should use the value from the OS.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy