Bad time on init ...

[Joseph S. D. Yao]

> From: seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt
> Message-Id: <8704142123.AA05061 at 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 at 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 at 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 at 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