Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!rutgers!bellcore!texbell!uhnix1!sugar!peter
From: peter@sugar.uu.net (Peter da Silva)
Newsgroups: comp.sources.bugs
Subject: Re: Flame: Problem with zoo: restoring times
Keywords: GMT time
Message-ID: <3481@sugar.uu.net>
Date: 21 Feb 89 12:54:03 GMT
References: <2884@mhres.mh.nl> <5930001@eecs.nwu.edu> <3453@sugar.uu.net> <1989Feb20.183931.13918@gpu.utcs.toronto.edu>
Organization: Sugar Land Unix - Houston, TX
Lines: 27

In article <1989Feb20.183931.13918@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes:
> Let me say that another way:  store file times in zoo archives as GMT.

I understood it the first time.

> This will mean that zoo will be 100% compatible with Unix.  For those
> machines that do not keep time interally as GMT, zoo can be compiled
> locally with a given time conversion constant such that it can adjust
> GMT times in archives to match local time.

Zoo, in general, cannot be 'compiled locally'. The vast majority of Zoo
users don't have compilers and don't *care* what time zone they're in.
They just know they downloaded it from a BBS and it does a better job
than ARC.

People in the past have written programs that expected a TZ variable on non-
UNIX systems. People just never bothered to set it.

There are two useful alternatives: (1) Store local time and GMT, or (2) Store
local time and timezone. These alternatives are equivalent, and the second
takes less space. QED.

Just because there was a bug in the implementation doesn't mean the design
decision was wrong.
-- 
Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net      'U`