The swich with dailight savings time

[Israel Pinkas]

In article <9 at phlpa.UUCP> scott at phlpa.UUCP (Scott Scheingold) writes:

> I have noticed that some of my cron jobs are running an hour later
> than they are normally run. Example uucp.cleanup is supposed to
> run at 23:45 but it is running at 00:45 instead. This has occured
> since the swich to EDT. The system swiched the time on sunday
> just like we would change the clocks automaticly. Now not all the
> jobs are running late just some. Have I come across a bug with
> SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should
> do to get things back on track (besides a reboot of the system).
> I was supprised when I found the clock had changed. I am just glad
> that I didn't have anything of real importance that needed to be
> run at a specific time. My next question would be when we switch
> back to EST will this become a problem once again.

This problem is a basic result of the PC style architecture.  (However,
AT&T could have solved this in software.)

The PC architecture's battery powered clock stores the date and time (year,
month, day, hours, minutes, seconds).  Most other architectures just have a
counter that counts seconds or clock ticks.

When Unix (SysV, but this may also apply to BSD and Mach) boots, a program
called setclk reads the hardware clock and sets the CMOS counter for the
kernel.  The timer interupt handler keeps the CMOS counter updated.  (Some
variations of the PC maintain the CMOS counter without software
intervention.)  The CMOS counter stores Unix time, which is the number of
seconds since 12:00 am, Jan 1, 1970 GMT.  This is the time that most
systems maintain in the battery powered clock.

As long as a PC is on, the system knows the true time.  When the switch to
DT occurs, and the TZ environment variable is set, date (and all the
library routines) report the time in DT.

However, when the system is rebooted, the hardware clock is read, and
setclk believes the battery powered clock.  Since it is DT, setclk assumes
that the time is in DT.  The assumption is that since the system could be
booted in DOS, the user might have set the battery powered clock from DOS
to DT.  Lousy assumption, IMO.

The quick and easy solution is to set the date as soon as possible after
the clock changes.  date sets the batter powered clock.

The correct solution to the problem is to modify setclk to assume that the
battery powered clock is always on standard time.  This is probably a more
reasonable assumption for two reasons:  (1) most people do not switch their
systems between DOS and Unix very often, and (2) many DOS users leave their
system on ST all year, BECAUSE DOS has no concept of DT.  (Blame IBM and
Microsoft for that.)  If you do this, you will need to make changes in your
kernel so that the date command sets the battery powered clock on standard
time.

Another alternative, if you leave your system up all the time is to have a
cron entry like this:

	0 3 * 4,10 0 "date `date +%m%d%H%M`"

date sets the battery powered clock (as a side effect).  This crontab entry
sets the date and time to the current date and time at 3 am every Sunday in
April and October.  Since the time date reports is correct right after the
switch to and from DT, this should work.  Your mileage may vary, and you
may have to change the format for date.

A third way of doing this (if you don't have source) would be to run a
script from either the crontab or the at queue (resubmitting itself) that
advanced the clock one hour in the spring and set the clock back in the
autumn.  Care should be taken that the script can only work once, and that
it correctly determines whether the time date reports is off by an hour.
(Looking at the system uptime would be one way.)

If you run rdate, you should not run the daemon on SysV/386 machines, as
they will mess up the network time.  You could make them update from the
network, though.

Hope this helps.

-Israel Pinkas

--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.

UUCP:	{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!st860!pinkas
ARPA:	pinkas%st860.intel.com at relay.cs.net
CSNET:	pinkas at st860.intel.com