avolio@grendel.UUCP (Frederick M. Avolio) (03/26/85)
> > Well, it seems that all 4.2BSD machines in Europe went on > DST a week too early this year... One other solution --- I believe this is good for any 4.2bsd based U*ix. When you configure the system specify dst followed by a number. 1 = usa, 2=australia, 3=w. europe, 4=central europe, and 5= e. europe. -- Fred Avolio {decvax,seismo}!grendel!avolio 301/731-4100 x4227
jmrm%eng-dsl.cam@UCL-CS.ARPA (James Matheson) (03/27/85)
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().
gwyn@BRL-VLD.ARPA (VLD/VMB) (03/27/85)
Another solution is to do what NBS did with WWV and change over to using just Universal Time.
leif@erisun.UUCP (Leif Samuelsson) (03/28/85)
In article <471@grendel.UUCP> avolio@grendel.UUCP (Frederick M. Avolio) writes: >> >> Well, it seems that all 4.2BSD machines in Europe went on >> DST a week too early this year... > > One other solution --- I believe this is good for any 4.2bsd >based U*ix. When you configure the system specify dst followed by a >number. 1 = usa, 2=australia, 3=w. europe, 4=central europe, and 5= e. >europe. This isn't the problem. The code is *wrong* for group 3 and 4 of the above. If we hadn't specified a "4" for our machine, we would have had to wait another *month* for DST to happen. (It's this sunday, folks!) It's hard work to correct the code in ctime.c for a system administrator, even with the sources, because it does not reside in the kernel. It is linked in with every routine that deals with time, like "date". I think a solution would be to handle the timezone and dst business with the "date" command and have the algorithms in the kernel instead. That way you could specify the timezone and dst in your /etc/rc like this: date -tMET -d4 Leif Samuelsson Ericsson Information Systems AB ..mcvax!enea!erix!erisun!leif Advanced Workstations Division S-172 93 SUNDBYBERG 59 19 N / 17 57 E SWEDEN
leif@erisun.UUCP (Leif Samuelsson) (03/31/85)
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? ---- Leif Samuelsson Ericsson Information Systems AB ..mcvax!enea!erix!erisun!leif Advanced Workstations Division S-172 93 SUNDBYBERG 59 19 N / 17 57 E SWEDEN