Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cuae2!ihnp4!ptsfa!lll-lcc!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.bugs.misc
Subject: Re: diffs for ctime.c for new DST rules, v7 systems
Message-ID: <13253@sun.uucp>
Date: Fri, 13-Feb-87 00:34:44 EST
Article-I.D.: sun.13253
Posted: Fri Feb 13 00:34:44 1987
Date-Received: Sat, 14-Feb-87 13:56:17 EST
References: <1565@lsuc.UUCP> <1151@ukecc.uky.csnet> <1569@lsuc.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 8

>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.

Only for suitable values of "OK".  The UNIX notion of time will be
off by one hour, so all times recorded on the file system (either in
inodes or in data files as UNIX time) will be incorrect.