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: <1569@lsuc.UUCP>
Date: Wed, 11-Feb-87 07:33:36 EST
Article-I.D.: lsuc.1569
Posted: Wed Feb 11 07:33:36 1987
Date-Received: Wed, 11-Feb-87 20:47:10 EST
References: <1565@lsuc.UUCP> <1151@ukecc.uky.csnet>
Sender: dave@lsuc.UUCP
Reply-To: dave@lsuc.UUCP (David Sherman)
Organization: Law Society of Upper Canada, Toronto
Lines: 27
Summary: official updates should certainly be used, if available

In article <1151@ukecc.uky.csnet> edward@ukecc.UUCP (Edward C. Bennett) writes:
>In article <1565@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes:
>>	Below is a diff for /usr/src/libc/gen/ctime.c
>>for v7 systems
>
>I think we've all seen this coming, but shouldn't the writers of our
>respective flavors of UNIX be providing the fixes. I'm not knocking
>David's good intentions, but the DST switch can be viewed as a MAJOR
>software bug worthy of an OFFICIAL update.

Absolutely.  But no-one ever maintained v7 systems very officially,
and I doubt anyone does now.  By all means, if you have a UNIX
which is "supported" (say by H-P, DEC or AT&T), lean on your
suppliers to fix the problem.

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.

We have a CT MiniFrame running CTIX (Sys V), by the way. I've
assumed that for that system I may just hack TZ during the relevant
three weeks...

David Sherman
-- 
{ seismo!mnetor  cbosgd!utcs  watmath  decvax!utcsri  ihnp4!utzoo  } !lsuc!dave