Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.sources.bugs
Subject: Re: Flame: Problem with zoo: restoring times
Keywords: GMT time
Message-ID: <5798@bsu-cs.UUCP>
Date: 21 Feb 89 01:18:22 GMT
References: <2884@mhres.mh.nl> <5930001@eecs.nwu.edu> <3453@sugar.uu.net> <1989Feb19.134220.29438@gpu.utcs.toronto.edu> <3465@sugar.uu.net> <1989Feb20.183931.13918@gpu.utcs.toronto.edu>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 23

In article <1989Feb20.183931.13918@gpu.utcs.toronto.edu> woods@gpu.utcs.UUCP
(Greg Woods) writes:
   ...store file times in zoo archives as GMT...This time conversion
   constant would be supplied by the person who installs zoo on a given
   system.  [could use an environment variable or a config file etc.]

There are two problems with this.  First, it forces the end user to
go through an installation step.

Second, it forces the code inside zoo to know about daylight savings
algorithms.  These are different all over the world and vary from time
to time at the whim of legislators.  Maintaining knowledge of daylight
savings is easier to handle if you have a mainframe with a paid system
administrator.  It's harder to educate users of microcomputers about
it.  I don't want to force users to update their configuration file
twice a year, or (alternatively) add information in the config file
about when daylight savings time is in effect.

Portable software ought to work correctly even if information about
timezone is not available.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
                    ARPA:  bsu-cs!dhesi@iuvax.cs.indiana.edu