From: seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt Message-Id: <8704142123.AA05061@hpfcla> Date: Tue, 14 Apr 87 14:55:55 EST Subject: Re: good news; missing person
[from me]
That's what I thought, too. But because people were not setting the correct time before coming up multi-user, on a System V Rev 2 V 2.0, I put the little rc (bcheckrc?) that sets the date as the last thing before a single-user shell, as well as the first thing after. Now I get calls that the time is not set properly by this ... I haven't yet investigated this properly, but it seems that the TZ is lacking here somewhere.
[ the exact nature of the problem hadn't come across right, yet. ]
The correct place to set TZ is in init. I have toyed with the idea of adding a new type of line to inittab which can be used to set TZ in init so that all of init's children can know about TZ.
This was actually n o t the problem. If TZ is not set, the new code just looks at "localtime", and reads that. I should have remembered that, and interpreted the statement of the problem in light of that. The r e a l problem was that when anyone tried to s e t the time (at init or otherwise), it came up 10 hours off! When I finally got this statement of the problem, the actual location of the problem was obvious. You know it, too, when you know that we are in the US Eastern time zone, at -5 hours (+18000 Unix seconds) from GMT:
Date: Sat, 11 Apr 87 08:08:49 +1000 Message-Id: <12085.545090929@munnari> From: Robert Elz <seismo!munnari!kre> Date: Fri, 10 Apr 87 11:52:31 cst From: ihnp4!infoswx!lan000!rfw Message-ID: <8704101752.AA13197@infoswx.UUCP> In my experience, the "timezone" variable on USG systems is always positive -- that is, application code subtracts its value from the current time, rather than adding it. This indicates a real bug, though your precise wording is incorrect. The real problem is that timezone is the opposite sign than it ought to be, and the fix is simply to negate it (always .. not just when it would otherwise be negative), ... Its probably indicative of just how little used this variable is incidentally, that this bug wasn't noticed before! If there was ever good evidence to simply kill "timezone" then I think this is it!
This is, of course, the problem, since in System V 'timezone' is n o t "little used", but is used all over the place! Date uses it when setting the date. Touch, acctcom, uusub, many SCCS programs, and others (I did a 'find' on a machine far from here) use it. If it should be +5, and it is -5, that gives a 10-hour difference, which is exactly the observed problem. (As observed, it was correct for ISO conventions, but that doesn't cut it with code that assumes the opposite.) All assignments to 'timezone' were converted to negative of what they had been, all those programs (*sigh*) were re-compiled, and everything worked again. Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy