Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!hplabs!nsc!nsta!instable!amos
From: amos@instable.UUCP
Newsgroups: comp.bugs.misc
Subject: Re: diffs for ctime.c for new DST rules, v7 systems
Message-ID: <693@instable.UUCP>
Date: Tue, 17-Feb-87 02:12:04 EST
Article-I.D.: instable.693
Posted: Tue Feb 17 02:12:04 1987
Date-Received: Tue, 17-Feb-87 23:03:09 EST
References: <1565@lsuc.UUCP> <1151@ukecc.uky.csnet> <1569@lsuc.UUCP> <13253@sun.uucp>
Reply-To: amos%nsta@nsc.com (Amos Shapir)
Distribution: world
Organization: National Semiconductor (Israel) Ltd.
Lines: 19

I always thought the whole idea of the BSD way of determining the dst was
extermely redundant - in contrast to the sysV method, in which anyone can
choose whether to have it or not any time, in run time, per process run;
on BSD systems it's a big and ugly routine, compiled into every utility,
and cannot be changed except by root, and then only globally.

It seems all the effort is invested only to present the creating time
of old files as it was at the time of creation - while programs (eg make)
that use it couldnt care less!

In Israel, where dst is erratic (the algorithm depends on the political
constellation and the phases of the moon - no :-) !) I use a small program
that changes the timezone by the settimeofday sys call, and is run twice
a year by 'at'.
-- 
	Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel
(011-972) 52-522261  amos%nsta@nsc.com 34.48'E 32.10'N