Addition to Arthur Olsen/4.3bsd table-driven ctime

[Robert Elz]

I understand your point of view, and having localtime fail backwards
to be compatible with old ctime's in situations where the tables
aren't installed has some appeal.  I was away when this was being
discussed originally, so I didn't have a chance to say anything.

However, this seem to depend a lot on the environment, if you
have basically stand-alone machines (or networked in a bunch to
each other only .. where by networked I don't include trash like
uucp and csnet), and which are probably mostly binary licensed
hosts, so they can't simply install the fixes themselves, then your
solution is probably a good one.  Probably Tektronix could
distribute a version like that to its clients (as could other
similar companies).

In other environments though (SUN would probably be one), its
probably more important that GMT stay accurate for network timimg
functions than that a few commands might report incorrect time
for a while because they are using an old version of ctime.
That is, I feel that "fiddling the clock" is a terrible thing to
do to the system, I'd almost allow *all* commands to report the
wrong time rather than allow that.

Even now I have a whole host of commands that I've never bothered
to recompile to use the table driven ctime.  I don't really care
if the /Y command in adb prints the wrong time for those couple of
weeks every time daylight saving switches on & off, and recompiling
it is more effort than I feel inclined to take just at the minute.
In Australia the table driven version has been wrong since Mar 86
and both transitions are wrong, so I've survived 3 error periods
like this so far.  I think cron is another that hasn't been recompiled,
making some daily jobs run an hour from when they should .. big deal.

Also, your solution solves only half the problem .. if someone gets
a binary from a "new ctime" site and runs it on an "old ctime" system,
then your solution will make the "new ctime" transparent.  But, if
someone takes a binary from an "old ctime" system, and runs it on a "new
ctime" system, then that binary will not function properly.  There's
no way I can think of to solve this.  Possibly its not a very common
situation.

I should say that I can't think of any particularly good reason for
making localtime fall back to compiled in tables (updated ones) if
the zoneinfo file isn't found.  That might happen if some site only
installed the zoneinfo files that they feel they need, and not ones
suitable for the whole (non solar) world.  Then a user wanting to
use some non installed zone would get host local time instead
of something indicating more clearly an error, which GMT is
intended to do.  I'm not sure that GMT-2:00 or something might
not be a better default (a zone that has almost no-one in it, so
its chance of being valid is less than GMT - that is somewhere
mid Atlantic - I mean ISO GMT-02:00 not Unix GMT-02:00 which would
be Eastern Europe, or most of Europe with DST).

Anyone who installs the table driven localtime should certainly install
the tables with it.

It would be tempting to make commands whose sole purpose is to
print the date (like date(1)) check the legality of the zone
info and print some error message if its incorrect, but I'm not sure
how much that would break (shell scripts).  Certainly I think it should
check when in setting the date mode.  Perhaps a new command to print
the date and check the TZ variable for sensibility, printing an error
if its no good rather than the time would be a useful thing to have.

kre