Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: 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

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