Article View: comp.bugs.misc
Article #67Re: diffs for ctime.c for new DST rules, v7 systems
From: brandx
Date: Sun, 15 Feb 1987 21:00
Date: Sun, 15 Feb 1987 21:00
18 lines
1583 bytes
1583 bytes
In article <1569@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes:
>Incidentally, what happens if you can't fix it? I suppose you
>could simply set the clock (i.e., count of time in seconds) forward
>an hour on April 5 and back on April 26. Then, as long as your
>software is never fixed, all times reported will be apparently OK.
Be careful if you're going to set the clock to get around the problem.
1) Setting the clock forward an hour will not change the fact that
the system will still view the time as Standard Time.
2) You'll have to wait until 4AM to move the clock back on the 26th.
Remember, the hour between 2 and 3 AM doesn't exist on the day
you're moving the clock back. (A minute before 3 AM is 1:59 AM,
not 2:59 AM.) The software is smarter than you think here.
I tried to set the clock back an hour after setting it
forward to 3:15 on April 26. As makes perfect sense, the time
changed to 1:15.
Howard Weisberg
Technical Details
Message-ID:
<1734@ihlpl.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ptsfa!ihnp4!ihlpl!brandxReferences:
<1565@lsuc.UUCP> <1151@ukecc.uky.csnet> <1569@lsuc.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ptsfa!ihnp4!ihlpl!brandx From: brandx@ihlpl.UUCP Newsgroups: comp.bugs.misc Subject: Re: diffs for ctime.c for new DST rules, v7 systems Message-ID: <1734@ihlpl.UUCP> Date: Sun, 15-Feb-87 16:00:25 EST Article-I.D.: ihlpl.1734 Posted: Sun Feb 15 16:00:25 1987 Date-Received: Mon, 16-Feb-87 19:09:05 EST References: <1565@lsuc.UUCP> <1151@ukecc.uky.csnet> <1569@lsuc.UUCP> Reply-To: brandx@ihlpl.UUCP (55236-Weisberg,H.) Organization: AT&T Bell Laboratories Lines: 18