[unix-pc.general] Daylight Savings Time -- works okay now

wilber@alice.UUCP (Bob Wilber) (04/05/89)

Rob Stampfli gave the sanest explanation of the chronological madness that took
place last night.  Between various reboots, reconversions of the binaries, and
different settings of TZ, smgr (no shared libraries) and date (shared
libraries) were either 1 or 2 hours behind, and agreed with each other about
half the time.  When I finally got them to agree with each other and got date
to fess up that it was EDT I manually set the time and rebooted, and it's been
okay since.  Resetting from the hardware clock was undoubtably the culprit.

And my thanks to Rob for reminding us to convert ctime.o in libp.a.

Bob Wilber    wilber@research.att.com

gst@gnosys.UUCP (Gary S. Trujillo) (04/07/89)

In article <9153@alice.UUCP> wilber@alice.UUCP (Bob Wilber) writes:
> ... 
> And my thanks to Rob for reminding us to convert ctime.o in libp.a.
> 
> Bob Wilber    wilber@research.att.com

Hmmm.  I just went looking for libp.a to patch it, and discovered that
I don't have one, as such.  What I do have is a /lib/libp directory that
looks as follows:

	drwxr-xr-x  2 bin     bin          64 Oct  1  1987 libp

	/lib/libp:
	total 403
	-r--r--r--  1 bin     bin      197462 Oct  1  1987 libc.a
	-r--r--r--  1 bin     bin        8596 Oct  1  1987 libmalloc.a

I checked my listings of what's what on the development set floppies,
and discovered that this situation is what one would expect after having
installed said development set:

	40775  bin         0  Apr 20 18:21:51 1987  lib/libp
	100644 bin    197462  Jan  1 13:10:00 1970  lib/libp/libc.a
	100644 bin      8596  Jan  1 13:10:00 1970  lib/libp/libmalloc.a

(Don't worry about the timestamps, I purposely set them to the date when I
did my system installation, just to make incremental dumps easier.)

However, this alternate libc.a does indeed have a ctime.o that has the
old value for the DST-changing date, and which succumbs quite nicely to
Lenny and Gil's recently-posted patch routine.  Thanks again, guys!

    partial output of "cmp -l /tmp/libc.a /usr/lib/libp/libc.a:

	18864 167 140

-- 
Gary S. Trujillo			      {linus,bbn,m2c}!spdcc!gnosys!gst
Somerville, Massachusetts		     {icus,ima,stech,wjh12}!gnosys!gst

wilber@alice.UUCP (Bob Wilber) (04/08/89)

Gary S. Trujillo writes:
}...
}Hmmm.  I just went looking for libp.a to patch it, and discovered that
}I don't have one, as such.  What I do have is a /lib/libp directory that
}looks as follows:
}...

Well, yes, I meant libp/libc.a, of course.

Bob Wilber