Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mikros!mwtech!mecky!walter
From: walter@mecky.UUCP (Walter Mecky)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO 'date'
Message-ID: <819@mecky.UUCP>
Date: 22 Nov 90 15:52:35 GMT
References: <2@mport.COM> <931@iiasa.UUCP> <1990Nov07.014539.10187@scuzzy.in-berlin.de> <1990Nov8.001536.10818@dell.dell.com> <7@mport.COM>
Reply-To: walter@mecky.UUCP (Walter Mecky)
Organization: MIKROS Systemware, Buettelborn/W-Germany
Lines: 24

In article <893@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes:
< Hello.  I'm running SCO Sys V/386 3.2.1 (ODT 1.0).  What the hell is wrong
< with the 'date' command?  It actually seems to overwrite the CMOS clock!

Yes it does. Suppose it's another nasty bug, because for setting the CMOS
clock there is "setclock".

< I got sick of having to enter the correct time upon bootup, so I deleted
< a few lines from /etc/asktimerc, so that all it does is essentially a
< "date `setclock`".  This works roughly half the time.  The other half of
< the time, the date ends up being a few hours off (not minutes, always hours).
< The weird thing is that entering "date `setclock`" from the command line
< actually advances the CMOS clock by 5 hours, every time.  Anyone out there
< have problems like these?  Any solutions?

I made the same experiences. The reasons are, that "date" takes your
timezone (according to TZ in the environment) and "setclock" does not.
I solved the problem in temporary unsetting TZ:

	TZ= date `setclock`

Hope that helps.
-- 
Walter Mecky	[ walter@mecky.uucp	or  ...uunet!unido!mecky!walter ]