ATT System V Rlease 3.1 and Timezones
Fri Dec 12 19:19:52 UTC 1986
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
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
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
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?
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.
More information about the tz