Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!think!mit-eddie!uw-beaver!tektronix!teklds!copper!stevesu
From: stevesu@copper.UUCP
Newsgroups: comp.unix.wizards
Subject: Yet Another Solution to the ctime problem
Message-ID: <950@copper.TEK.COM>
Date: Mon, 30-Mar-87 22:46:35 EST
Article-I.D.: copper.950
Posted: Mon Mar 30 22:46:35 1987
Date-Received: Wed, 1-Apr-87 05:49:25 EST
Reply-To: stevesu@copper.tek.com (Steve Summit)
Distribution: na
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 56

I have come up with a last-minute addition to the set of ways of
dealing with the daylight-savings time change this weekend.
It is based on the following three assumptions:

	Compiling DST information into ctime.o and hence linking
	it into the a.out file of every program that deals with
	time is a total loss.  Some sort of dynamic reading from
	a file is the only way to go.

	Artificially setting the time off by an hour for three
	weeks is for the birds.  (This is what several vendors
	are recommending.)  If I wanted to set my system clock
	periodically to account for DST, I'd run VMS.

	I don't have source for all of my systems, and even if I
	did, I wouldn't feel like relinking everything, because
	it's a lot of work, and I might not have .o files lying
	around so I might have to recompile things too, and then
	I might break utilities whose sources were out-of-date.

I have worked out the following two-step solution:

	1. Some simple mods to the existing ctime (actually
	   localtime) to allow it to read the DST information
	   from a file, but in a simple-minded enough way that
	   the size of ctime.o doesn't increase much.

	2. A patching link editor which, believe it or not, lets
	   you wedge the new copy of ctime into existing a.out
	   files, even if they don't have symbol table or
	   relocation information.

This scheme unfortunately does not use any of Arthur Olson's
remarkable solution, which is clearly the way to go if you're
going to relink everything.

It has been said that "using adb on the running kernel is not for
the faint-of-heart."  The same is true for patching a.out files.
If you're not up for a nerve-wracking trek through the bowels of
Unix, involving adb, assembly language, relocation, and hidden
library routines, just relink your executables if you're able to
and set your clock fast for three weeks if you aren't.

I don't think I'm going to post the patching link editor yet, but
I'll send you a copy if you're really interested.

(If it sounds like I've changed my tone since the beginning of
this article, it's because these last three paragraphs are being
written after I started doing wholesale patching of lots of files
in /bin and friends, and discovering that writing the patcher,
which is as far as I'd gotten when I wrote the first part of the
article, did not leave me home and dry.  I wasn't even home and
vigorously toweling myself off.)

                                           Steve Summit
                                           stevesu@copper.tek.com