Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
I cannot be sure that my customers will install the necessary timezone support files.
Neither can you be sure that they will install /etc/passwd. You don't handle that, why handle this?
/etc/passwd is standard on the systems I'm selling to; /etc/zoneinfo isn't (yet). A customer doesn't have to install /etc/passwd to get my software to run; I know he already has it, or else he's got a broken system, and it's his problem, not mine.
I insist that both timezone and DST corrections be applied, even in the absence of /etc/zoneinfo, which means that ctime must carry some DST information along in its data segment, so it can perform at least as well as it used to.
This is unclear to me.
What I'm worried about here is systems that haven't applied any fixes. I detest "two steps forward, one step back" improvements, so I'm trying to arrange that a ctime that I link into my code behave 100% backwards-compatibly when shipped to a site that depends on using the old ctime. By "backwards-compatibly," I mean that any new ctime, when operating in an environment without /etc/zoneinfo, must generate the same results as (i.e. localtime must be functionally identical to) the "old" versions of ctime. If not, there will be periods of time (such as the three-week period when lazy and/or sensible systems simply set their clock ahead by an hour) during which the new version of ctime will generate a different local time value than the rest of the utilities on the system (date, ls, anything linked with the old ctime) when presented with the same kernel timestamp.
The next question is, should any DST information hard-compiled into ctime be fixed to reflect recent changes? The surprising answer is "no."
That means that your worst case is off by an hour. (Ignoring double DST.) The same as 4.3's. What am I missing?
No. It's off by 0 hours, at all times of any past or present year, when shipped to a system that applies no fixes. (Actually, there is a worse worst case, that of the site that applies the fixes in Article 13, to arrive at a temporarily fixed but still non table-driven ctime. I can't arrange for things to work correctly in this case without breaking things in the other two cases, and I consider the other two cases -- the no fix case and the Arthur Olsen case -- more likely.) Actually, no one else here at Tektronix is at all concerned about this issue, and the witching hour has come and gone, so it's probably not worth our thrashing this out. I thought my arguments were fairly convincing, and I tried to sweeten the pot by offering working code, but I admit that these are pretty fine points I'm considering, and since nobody else seems to be interested, I think I'll drop the whole thing and go off and find other damsels to rescue :-). Steve Summit
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
participants (2)
-
Robert Elz -
Steve Summit