Flame: Problem with zoo: restoring times

Rahul Dhesi dhesi at bsu-cs.UUCP
Tue Feb 21 11:18:22 AEST 1989


In article <1989Feb20.183931.13918 at gpu.utcs.toronto.edu> woods at 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 at iuvax.cs.indiana.edu



More information about the Comp.sources.bugs mailing list