Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.lang.c
Subject: Re: Daylight Savings Time
Message-ID: <805@mit-eddie.UUCP>
Date: Fri, 20-Dec-85 00:40:33 EST
Article-I.D.: mit-eddi.805
Posted: Fri Dec 20 00:40:33 1985
Date-Received: Sat, 21-Dec-85 04:39:31 EST
References: <124@brl-tgr.ARPA> <1727@uw-beaver> <1679@hammer.UUCP> <641@mit-eddie.UUCP> <126@hadron.UUCP>
Reply-To: barmar@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, Cambridge, MA
Lines: 48

In article <126@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
>In article <641@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes:
>>On Multics, the date/time conversion software includes a table listing
>>many of the world's time zone names (in several languages, no less),
>>along with the corresponding difference from GMT.  ...
>
>Nice, but nothing special and not unique to Multics.  I had this
>working on an old PWB 1.0 system quite a few years ago.


Good for you.  However, most of the participants here don't seem to be
so lucky.

>>                             -- the system administrators merely change
>>the default time zone twice a year (if necessary -- our primary exposure
>>system is in Arizona, which doesn't use DST).  Many of our customers are
>>outside the US, so hardcoding our DST rules would have been a nightmare.
>
>Many systems don't have system administrators (at least not ones who
>are like you and me and know how to wreak magic), and so it is nice
>if they automagically put in the correct times.

Most systems have someone who turns it on.  It doesn't take much more
smarts to tell the system what time zone it is in twice a year.  Many
digital clocks make it harder than it would be on the computer: run a
single set_system_time_zone command as root.

>If there is a
>computable algorithm, it can be expressed on the computer in some
>simple form, even if only via numerical methods.

But the problem is that it cannot always be expressed in any algorithm.
On Unix it currently is expressed in an algorithm, and that is going to
screw people if Congress changes the rules.  Hardcoding any DST
algorithm is like coding in rreagan (password "whitehouse") into
login.c.  It is guaranteed to be wrong in a few years and in other
countries.  I have heard that in some countries the switchover dates are
specified yearly.

With a command like the above, you get nice generality.  If a particular
system happens to be in an area with a regular pattern to the switchover
then the command can be put into crontab, so the sysadmin doesn't have
to do anything.  Of course, if Congress legislates a new set of dates,
only the crontab entries have to be changed.
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar