andy@piziali.lonestar.org (Andy Piziali) (04/10/91)
Israel, thank you for the detailed explanation of how UNIX systems typically
track the date, time, and daylight savings time (DST). I have a related
question because my system failed to change to DST last weekend.
I am running IBM Xenix 1.0, a Microsoft Xenix 3.0 derivative, and noticed that
the kernel didn't switch to DST. I expected the "date" program to report "CDT"
because my TZ environment variable has the value "CST6CDT." A little bit of
investigation revealed that the kernal had been built with a "master" file
whose "daylight" entry was zero, indicating DST was not to be used.
I rebuilt the kernel with "daylight DSTFLAG 1" in the /usr/sys/conf/master file
and "date" still doesn't report "CDT." I verified that the kernel's dstflag
is now set using the ftime(2) system call.
My question is: are the two dates which delimit the period of the year DST is
in effect hard coded into the kernel and could these dates have differed from
the current dates at the time this Xenix was written? I believe the kernel was
last altered in 1983 or 1984. What else should I look at to find out why Xenix
is not enabling DST?
--
Home: andy@piziali.lonestar.org |
{convex,egsner,frontier,laczko}!piziali!andy ________------+------________
Office: piziali@convex.com / \
{sun,texsun,uunet}!convex!piziali *---*pinkas@st860.intel.com (Israel Pinkas) (04/10/91)
In article <1991Apr10.114836.10816@convex.com> andy@piziali.lonestar.org (Andy Piziali) writes: > My question is: are the two dates which delimit the period of the year > DST is in effect hard coded into the kernel and could these dates have > differed from the current dates at the time this Xenix was written? I > believe the kernel was last altered in 1983 or 1984. What else should I > look at to find out why Xenix is not enabling DST? Congress changed the date for switching to DT in 1987. The old date was the LAST Sunday in April. The new date is the first Sunday in April. The October date was, and remains, the last Sunday. Since the old way was in use since we started this batch of DT (in the 70s?), and nobody expected the rules to change, the kernel may have the date hardcoded (as a rule). There was a lot of discussion on this when Congress changed the date. I believe that most people favored a text file that dictates when to switch, so that the rules could be updated as they changed. My system (SVR4) has files in /usr/lib/locale/TZ that appear to dictate rules for various timezone info. Hope this helps, -Israel -- -------------------------------------- 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
srodawa@vela.acs.oakland.edu (Ron Srodawa) (04/11/91)
I too have an EST->EDT tale of woe. I'm running Xenix/386 2.3.3. Last year it did the correct changes all by itself. This year, I have TCP/IP and I'm running timed, the network time daemon. Xenix advanced the time TWO HOURS! Any ideas about that one? Ron. -- | Ronald J. Srodawa | Internet: srodawa@vela.oakland.edu | | School of Engineering and CS | UUCP: srodawa@vela.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | |
peter@ficc.ferranti.com (Peter da Silva) (04/11/91)
In article <1991Apr10.114836.10816@convex.com> andy@piziali.lonestar.org (Andy Piziali) writes: > I am running IBM Xenix 1.0, a Microsoft Xenix 3.0 derivative, We're running Xenix 3.5 here. > My question is: are the two dates which delimit the period of the year DST is > in effect hard coded into the kernel and could these dates have differed from > the current dates at the time this Xenix was written? Yes, and yes. Every year, twice a year, we change TZ from CST6CDT to CDT5, and reboot the computers (or just log everyone out and restart cron). -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
djd@eos.arc.nasa.gov (Daniel J. Dasaro) (04/12/91)
I'd like to jump into this discussion because we're having trouble with our 4.3 BSD systems (which are running the ntp daemon also!). I noticed that in /usr/src/lib/libc/gen/ctime.c the rules for DST are defined. Ours was the old style (end of April) method. I modified the number 119 to 98 (day of the year to switch) and ran make in that directory, which created a new genlib. I recompiled the kernel and tried the new one but it still reads PST not PDT, even after I ran date to set the date. What I really need to know is where the trigger is to get the machine to make that switch to DST. I believe that if my new ctime is called, it will return PDT as the current timezone (according to the rules) but I'm not sure 'date' really does this. Will I have to run my new kernel overnight so cron can run and "do the change?" -Dan Dasaro (djd@eos.arc.nasa.gov)
peter@ficc.ferranti.com (Peter da Silva) (04/13/91)
In article <5776@vela.acs.oakland.edu> srodawa@vela.acs.oakland.edu (Ron Srodawa) writes: > I too have an EST->EDT tale of woe. I'm running Xenix/386 2.3.3. Last > year it did the correct changes all by itself. This year, I have TCP/IP > and I'm running timed, the network time daemon. Xenix advanced the time > TWO HOURS! Any ideas about that one? Xenix doesn't advance the time. It just changes the way time is displayed. Theory: Your timed is apparently picking up the time from some place that has the time advanced, converting it to UNIX time without knowing that you switched to DST, and then setting your clock. Other programs that know it's DST are then adding the hour as well. Solution: kill timed and restart it. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
gordon@sneaky.lonestar.org (Gordon Burditt) (04/14/91)
>I'd like to jump into this discussion because we're having trouble with our >4.3 BSD systems (which are running the ntp daemon also!). I noticed that in >/usr/src/lib/libc/gen/ctime.c the rules for DST are defined. Ours was the Notice also that ctime.c is not linked into the kernel. It is linked into lots of application and utility programs. If your ctime.c does not use an external file to determine the rules for DST, you need to modify ctime.c for the new rules. (Better to bite the bullet NOW and convert to using a file). Then you ***RELINK ALMOST EVERY EXECUTABLE IN THE SYSTEM*** (except the kernel) that uses ctime.c (really localtime()), including, of course, applications for which you don't have linkable object. comp.sources.unix had a very nice localtime package posted a few years back. It is possible to have a hodge-podge of programs, some that recognize the new rules (they were linked with the comp.sources.unix localtime package), and some that didn't (all the system-supplied programs in Tandy 6000 Xenix before Xenix 3.2.0 and the 3.2 development system upgrade, which didn't come out at the same time). The kernel in some systems contains defaults for the number of hours west of GMT, and whether or not the system EVER has daylight savings time. (Some areas in the United States don't, last time I checked). It does not contain the switchover rules. Gordon L. Burditt sneaky.lonestar.org!gordon