Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!jmrm%eng-dsl.cam@UCL-CS.ARPA
From: jmrm%eng-dsl.cam@UCL-CS.ARPA (James Matheson)
Newsgroups: net.unix
Subject: Re: Daylight Saving Time???
Message-ID: <9519@brl-tgr.ARPA>
Date: Wed, 27-Mar-85 06:00:47 EST
Article-I.D.: brl-tgr.9519
Posted: Wed Mar 27 06:00:47 1985
Date-Received: Sun, 31-Mar-85 04:26:22 EST
Sender: news@brl-tgr.ARPA
Lines: 21

Leif Samuelsson writes
> Well, it seems that all 4.2BSD machines in Europe went on
> DST a week too early this year. As I see it there are three
> possible solutions:
> 
> 1) Fix and recompile ctime.c if you have sources.
> 
> 2) Remove the dst flag from the config file for a week. (Save vmunix!)
> 
> 3) Reset the date for a week. This is clearly wrong but is probably
>    the easiest way out.
> 
> Any other suggestions?

Yes, do the daylight saving time decision in a utility which calls
settimeofday() to set the timezone information appropriately. This could
be called from cron on the days when the changes occur (in England this
is the subject of annual legislation and hence not suitable to compile in);
the current value can be saved for the same utility to read and set on
reboot. The current ctime() scheme seems to make very poor use of the
flexibility provided by the timezone info in {gs}ettimeofday().