ATT System V Rlease 3.1 and Timezones

[Guy Harris]

	1.  The  TZ  environment  is  set  and  maintained  in  the  file
	/etc/TIMEZONE  and is a Bourne shell file that can be sourced ( .
	/etc/TIMEZONE) by any one who wishes.

You'd better make that "can be source by any *Bourne shell* that wishes".
There is no guarantee whatosever that a given user will ever have a Bourne
shell running in their session; e.g., "uucp" usually has "uucico" as its
login shell.  "uucico" would have to read "/etc/TIMEZONE" itself, and pass
the first line in that file to "putenv" after stripping off the trailing
newline (remember, you do NOT want to permit the user to do

	TZ=EST5EDT uucp ...

in order to force "uucico" to think it's after 11PM and thus force it to
make the call to the target system immediately).

	3. The TZ variable has new syntax and fields.  First as sample
		TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00

This is totally wrong.  For one thing, as you point out later, it makes the
incorrect assumption that only the rules for the current year are of
interest.  For another, it sets TZ to a complicated string which also
requires work to generate; how many of you who don't happen to have
calendars that give Julian dates on every day page want to go through the
trouble of figuring Julian dates out?  (This is also a botch in the S5
accounting routines; you have to provide the Julian date of all the days to
be considered holidays.  A computer can figure that out much better than a
human can.)

Both Arthur Olson's and HP's schemes, which put the rules into a file and
which just provide the *name* of the file to fetch them from, are vastly
superior.  Olson's code includes a compiler that makes generating the rules
quite easy.

	5.  A new sequences of time functions [setcftime,ascftime,cftime]

Oh boy, just what we need, a *third* set of functions, different both from
ANSI C and from the HP-X/Open ones!  AT&T-IS should either drop these
functions in favor of one of the existing ones or get one or the other or
both bodies to adopt theirs.

	6.  A variable LANGUAGE is used to specifiy the language  of  the
	output  [default  is  ENGLISH  with /lib/cftime/usa_english ] the
	default file.  Files in /lib/cftime specify the default names and
	abbreviations  of the days and months, as well as default strings
	for  date  and  cftime  (Europeans  use  dd/mm/yy  and  USA  uses
	mm/dd/yy) and such.

HP's scheme, at least as presented in the X/Open stuff I saw, is much
better.  Instead of a set of files specific to time formatting, they provide
a general "string catalog", so that you can fetch messages, time and date
format strings, etc. for the particular language and cultural environment.
Having a "/lib/cftime" directory is just a hack.  (Also, what does the
LANGUAGE variable contain?  For the US, would it be ENGLISH or
"usa_english"?  The former is incorrect; I believe the date format in
Britain, for example, is different from that in the US, so just stating the
language is insufficient.)

	7.  The environment variable CFTIME can be used  to  specify  the
	default  format  string for cftime related functions and programs
	-- date now uses cftime.

Why is this necessary, if there is a LANGUAGE variable?

	Comments:
	The new syntax for TZ allows for any time  zone  rule,  but  only
	allows  ONE  change  per year.  The varialbe must be modified and
	reset for the year being printed.  Thus is TZ is set for  1987  a
	full ctime for a previous year will result in odd information for
	a few days each spring and fall (US).

It also doesn't look like it can handle things like South Australia's switch
from CST to EST.

	It seems like a trivial change to store a table of  TZ  variables
	for each year.

I hope by "store a table" you mean "store a table *in a file*".  This table
could get pretty big if you really want it to specify the rules for the
entire range of valid UNIX times.

All in all, none of this is very good.  Others have done it much better;
AT&T-IS would be best advised to leave this *all* out of the SVID, and be
prepared to do it differently in future releases.