rcpilz@ablnc.UUCP (03/12/87)
On April 5th at 2:00 AM, daylight savings time wil be in effect. This is 3 weeks earlier than normal. In UNIX System V, there is a library routine ctime(3C) which has the last weekend in April hardcoded into it rather than the first weekend. The program must be modified and recompiled along with 70+ programs that call ctime, ascitime, localtime, and date. If you are internal users of R&D UNIX (aka 452 UNIX), or DPCT UNIX supported systems, this fix will be automatic. If you buy AT&T UNIX System software, and you get monthly bulletins, there is a recommended fix. The fix is to make an entry in root's cron to adjust for daylight saving's time on Sunday morning of the 5th and to undo the adjustment on the 26th when ctime kicks in. This is nice on systems without source. I think the code modify of ctime.c and the recompile is a better fix. Still better is a feature in the future release of UNIX System software that has an /etc file similar to the /usr/lib/acct/holidays file that lets the administrator enter in the yearly on and off dates for daylight savings time. Even though it is yetanotherfile, it allows for system changes of local time differences without regenning the kernal. As for BSD, it may not even be an issue, I am unfamiliar with your internals. But check it out. Disclaimer: These are my opinions not my employers except where stated. -===- __ _______ _______ Robert Pilz --======= / \ |__ __| |__ __| AT&T DPCT ----======= / __ \ | | _____ | | Room 4SC24 =-----======= / / \ \ | | / _ \ | | 2301 Maitland Center Pkwy =-----======= | |__| | | | \ \ \_\ | | Maitland, Fl 32751 ==---======== | __ | | | / \ __ | | =========== | | | | | | | (\ / / | | ablnc!rcpilz ========= |_| |_| |_| \_____/ |_| (305) 660-6990 -===-
guy@gorodish.UUCP (03/12/87)
>I think the code modify of ctime.c and the recompile is a better fix. Still >better is a feature in the future release of UNIX System software >that has an /etc file similar to the /usr/lib/acct/holidays file >that lets the administrator enter in the yearly on and off dates >for daylight savings time. Massively better than that is the code posted to "mod.sources" by Robert Elz, written by Arthur Olson, Robert Elz, and others, that does NOT require the administrator to do ANYTHING unless the rules used to compute the start and stop dates for GMT change. Schemes that require the administrator to change something every year, to put it bluntly, suck; why force the *administrator* to do work that the *machine* can properly do? (For that matter, "/usr/lib/acct/holidays" isn't as good as it could be; it requires you to enter day-of-year for holidays, and that's *another* thing the machine should be computing given month and day values.) Olson's scheme also will permit "ctime" and company to properly convert times not in the current year - something which UNIX has been able to do up to now, at least for times in the past, and which schemes that *only* tell the system what the rules are for the *current* year will *not* permit UNIX to be able to do. Remember, "not in the current year" does not necessarily mean "a long time ago". Times "not in the current year" may be times that are less than 6 months ago; "ls" will print times as well as dates for dates/times less than 6 months in the past. Since this stuff was posted to mod.sources, people with source should replace "ctime.c" with the code there; then, once they've recompiled all the programs that use "ctime", "localtime", and company, they won't have to change them again in the future. >As for BSD, it may not even be an issue... It's an issue. It uses the same scheme that other UNIXes use; the only difference is that it gets the offset from GMT, and a code indicating which of the compiled-in rules it should use, from the kernel. It doesn't get the rules from the kernel.
kirk@ihopa.UUCP (03/12/87)
In article <245@ablnc.ATT.COM>, rcpilz@ablnc.ATT.COM (Robert C. Pilz) writes: > > On April 5th at 2:00 AM, daylight savings time wil be in effect. This is > 3 weeks earlier than normal. In UNIX System V, there is a library routine > ctime(3C) which has the last weekend in April hardcoded into it rather > than the first weekend. The program must be modified and recompiled > along with 70+ programs that call ctime, ascitime, localtime, and date. Does a change have to be made for October as well. Currently DST starts on the last Sunday of October. I'd hate to have to recompile again in October. -- Kevin Kulhanek ..!ihnp4!ihopa!kirk AT&T Bell Labs, Naperville, Il. (312) 979-5308