scott@phlpa.UUCP (Scott Scheingold) (04/08/91)
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. Just wondering, Scott Scheingold E-mail ...!lgnp1!phlpa!scott
rvdp@cs.vu.nl (Ronald van der Pol) (04/09/91)
>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 I think so. We run SCO 3.2.2 too :-( and our times are completely wrong: - it is 14:15 MET DST at the moment - 'date' says it is 13:15 MET - localtime(3) says it is 18:15 MET - our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' What is going on here?? -- Ronald van der Pol <rvdp@cs.vu.nl>
pinkas@st860.intel.com (Israel Pinkas) (04/10/91)
In article <9@phlpa.UUCP> scott@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@relay.cs.net CSNET: pinkas@st860.intel.com
tdc0010@dircon.co.uk (Ben Knox) (04/10/91)
rvdp@cs.vu.nl (Ronald van der Pol) writes: >I think so. We run SCO 3.2.2 too :-( and our times are completely wrong: >- it is 14:15 MET DST at the moment >- 'date' says it is 13:15 MET >- localtime(3) says it is 18:15 MET >- our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' >What is going on here?? I've noticed this at a couple of sites...it appears that SCO's timezone setting program doesn't work properly. It doesn't produce a TZ string in the correct format. It puts a comma instead of a semi-colon. EG, your TZ string should be: TZ='MET-1MET DST;M3.5.0,M9.5.0' (based on the string you gave originally). If you manually change this in the /etc/TZ file, all should work properly. Regards, Ben
klaassen@fifi.informatik.uni-dortmund.de (Othmar Klaassen) (04/11/91)
> I think so. We run SCO 3.2.2 too :-( and our times are completely wrong: > - it is 14:15 MET DST at the moment > - 'date' says it is 13:15 MET > - localtime(3) says it is 18:15 MET > - our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' Just a few hours ago we had the same trouble ... > What is going on here?? I can't tell exactly, but for us TZ == 'MET-1MST-2,M3.5.0,M9.5.0' works far better, it seems as if not giving the number for the daylight saving time (absolute from GMT!) doesn't give you a default of 1 hour (relative) but the default where SCO was written :-( either you try /etc/tz (but watch the result!) or you edit /etc/TIMEZONE (and reboot in either case). as for the man pages (timezone, ctime): specs? what specs... hope it helps, Othmar
news@rushpc (Usenet news administrator) (04/11/91)
>I think so. We run SCO 3.2.2 too :-( and our times are completely wrong: > >- it is 14:15 MET DST at the moment >- 'date' says it is 13:15 MET >- localtime(3) says it is 18:15 MET >- our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' > >What is going on here?? > > >-- > Ronald van der Pol <rvdp@cs.vu.nl> While we're on the subject, I was just curious, how do non-American sites handle Daylight Savings time? You're not subject to the whims of our Congress. Do you use Daylight savings time? Is there a brand of UNIX that is cognizant of your laws or do you just live with it? -- John Rushford ------------- Westminster Colorado
chris@ukelele.UUCP (Chris Linstruth) (04/11/91)
pinkas@st860.intel.com (Israel Pinkas) writes: > >In article <9@phlpa.UUCP> scott@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 >> .. stuff deleted .. >> 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. > >... makes some valuable suggestions ... I dealt with this problem by setting the hardware clock to GMT and setting the system clock at boot time with: : # @(#)bsetdate.sh 1.1 TZ=GMT0;export TZ date `/etc/setup -d` > /dev/null . /etc/TIMEZONE echo "System time: \c" date setup -d outputs the CMOS clock setting in a date(1) parsable format. This is on uPort V/AT and Daylight to Standard time switches have been automatic and effortless for two years. cron even seems to be executing jobs at the appropriate times. -- Chris Linstruth ____ ___ The Genuine Aloha Ukelele chris@ukelele.UUCP / \_/ \______OO (703) 960-8428 * 4 {uunet, rutgers}!mimsy - | (_) ______## 2400/1200 N-8-1 !prometheus!ukelele!chris \____/ \___/ OO UNIX For The Masses!
dick@ahds.UUCP (Dick Heijne CCS/TS) (04/11/91)
In article <9604@star.cs.vu.nl>, rvdp@cs.vu.nl (Ronald van der Pol) writes: > > - it is 14:15 MET DST at the moment > - 'date' says it is 13:15 MET > - localtime(3) says it is 18:15 MET > - our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' > I have NO problems with Xenix at all: - it is 14:15 MZT at the moment - so says date - so says localtime - MY TZ is 'MET-1MZT;M3.5,M9.5' 1. Replace the comma after DST by a semicolon (that should do it) 2. No result ? Replace the summer-mnemonic by a 3-character one 3. No result ? Leave out the trailing '.0' (is redundant anyway) 4. No result ? Call your local dealer. Dick.
rvdp@cs.vu.nl (Ronald van der Pol) (04/11/91)
news@rushpc (Usenet news administrator) writes: >While we're on the subject, I was just curious, how do non-American sites >handle Daylight Savings time? You're not subject to the whims of our >Congress. Do you use Daylight savings time? Is there a brand of UNIX >that is cognizant of your laws or do you just live with it? Most European countries switch to DST in the night saterday/sunday at 02.00 on the last week of march and switch back saterday/sunday 02.00 on the last week of september (except England/Ireland?). Have a look at a real computer and OS :-) like SunOS (/usr/share/lib/zoneinfo/europe) and probably most workstations. -- Ronald van der Pol rvdp@cs.vu.nl SunOS 4.1.1 :-) :-) rvdp@sow.econ.vu.nl SCO 3.2.2 :-( :-( -- Ronald van der Pol <rvdp@cs.vu.nl>
lars@iclswe.icl.se (Lars Tunkrans) (04/12/91)
rvdp@cs.vu.nl (Ronald van der Pol) 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 >I think so. We run SCO 3.2.2 too :-( and our times are completely wrong: >- it is 14:15 MET DST at the moment >- 'date' says it is 13:15 MET >- localtime(3) says it is 18:15 MET >- our TZ is 'MET-1MET DST,M3.5.0,M9.5.0' >What is going on here?? I dont think your TIMEZONE is rigth for SVR3.2 and Paris daylight time. Here is what I use for 1991 Paris time: TZ="MET-1DST-2;90/02,272/03" Unfortunatley we have a case of pretty wierd thinking here: Negative TIMEZONE values gives times east of Greenwich ( London ) while positive TIMEZONE values gives times west of Greenwich. And not the other way around which would be more logical, at least to me. So since Paris daylight time is 2 hours ahead of GMT, it needs to be defined with DST-2 otherwise UNIX dont know which time to shift to. There was no value assosiated with DST in your example above. lars. -- Lars Tunkrans Phone +46 (0)76096368. | I C L DRS Systems Support. | UUCP: uunet!mcsun!sunic!iclswe!lars | The leading UNIX System V Release 4.0 DOMAIN Address : lars@iclswe.icl.se | integrator.
tim@dell.co.uk (Tim Wright) (04/12/91)
In <9634@star.cs.vu.nl> rvdp@cs.vu.nl (Ronald van der Pol) writes: Stuff about timezones and DST deleted. >Have a look at a real computer and OS :-) like SunOS >(/usr/share/lib/zoneinfo/europe) and probably most workstations. FYI, System V Release 4 has the zic/zoneinfo stuff as well. It really is nice to have a system that copes with more than the USA :-) Tim -- Tim Wright, Dell Computer Corp., Bracknell | Domain: tim@dell.co.uk Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim Smoke me a Kipper, I'll be back for breakfast - Red Dwarf
rvdp@cs.vu.nl (Ronald van der Pol) (04/17/91)
tim@dell.co.uk (Tim Wright) writes: |In <9634@star.cs.vu.nl> rvdp@cs.vu.nl (Ronald van der Pol) writes: |Stuff about timezones and DST deleted. |>Have a look at a real computer and OS :-) like SunOS |>(/usr/share/lib/zoneinfo/europe) and probably most workstations. |FYI, System V Release 4 has the zic/zoneinfo stuff as well. It really is |nice to have a system that copes with more than the USA :-) But SVR4 is a **real** operating system :-) -- Ronald van der Pol <rvdp@cs.vu.nl>