Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!lsuc!dave
From: dave@lsuc.UUCP
Newsgroups: comp.bugs.misc
Subject: Re: diffs for ctime.c for new DST rules, v7 systems
Message-ID: <1583@lsuc.UUCP>
Date: Thu, 19-Feb-87 07:41:17 EST
Article-I.D.: lsuc.1583
Posted: Thu Feb 19 07:41:17 1987
Date-Received: Fri, 20-Feb-87 01:21:36 EST
References: <1565@lsuc.UUCP> <1151@ukecc.uky.csnet> <1569@lsuc.UUCP> <13253@sun.uucp>
Sender: dave@lsuc.UUCP
Reply-To: dave@lsuc.UUCP (David Sherman)
Organization: Law Society of Upper Canada, Toronto
Lines: 19
Summary: !(!ok) == ok

In article <13253@sun.uucp> guy@sun.UUCP (Guy Harris) 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.
>
>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.

Note that I said, "as long as your software is NEVER fixed". The
internal time may be incorrect, but it would forever (when referring
to times between April 5 and April 27/87, for example) get it "right"
when converting it through localtime().

David Sherman
The Law Society of Upper Canada
-- 
{ seismo!mnetor  cbosgd!utgpu  watmath  decvax!utcsri  ihnp4!utzoo } !lsuc!dave