Xref: utzoo unix-pc.general:5710 comp.sys.att:9912
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!apple!bionet!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!pikes!aspen.craycos.com!sphere!ruck
From: ruck@sphere.UUCP (John R Ruckstuhl Jr)
Newsgroups: unix-pc.general,comp.sys.att
Subject: 3b1, why /etc/clockupd.wk?
Message-ID: <307@sphere.UUCP>
Date: 3 Jul 90 06:49:50 GMT
Followup-To: unix-pc.general
Organization: Private; Colorado Springs, CO
Lines: 36

The /usr/lib/crontab supplied with my 3b1 software has the following
entry:

    3 3 * * 0 /bin/su root % /etc/clockupd.wk > /dev/null

/etc/clockupd.wk is a simple shell script:

    #sccs	"@(#)fndetc:clockupd.wk	1.7"
    # Write to the hardware clock every Sunday morning to accomodate 
    # synchronization of time between s/w and h/w clock in case day light 
    # saving time is being used.  Wait a minute to prevent recursion.
    # Note: backslash needed to avoid SCCS conflict
    
    sleep 60
    date `date +%m%d%H\%M`
    
Why do we need to synchronize the clocks?  What looks directly at the
h/w clock rather than the s/w clock (besides the initialization of the 
s/w clock at boot-time.

And, if this truly synchronizes the clocks, why have they apparently
diverged so much withing 26 hours -- I run Vernon Hoxie's routine Monday
mornings to set my clock, and a typical log-file entry is:

    Mon Jun 18 05:21:51 1990, Sys. Corr: -37 sec. RTC Corr:  -6 sec.  50 dst

Showing (*I think*) a divergence of 31 seconds between the clocks
accrued during the 26 hours since the Sunday 3:30am synchronization.
But if the clocks were that inaccurate, I'd expect larger than 37s or 6s
absolute correction would be necessary after a full week (since the
previous Monday's correction).

Regards,
John.
-- 
John R Ruckstuhl, Jr	sphere!ruck, ruck%sphere@hp-col.col.hp.com