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