Flame: Problem with zoo: restoring times

Greg Woods woods at gpu.utcs.toronto.edu
Tue Feb 21 09:39:31 AEST 1989


In article <3465 at sugar.uu.net> peter at sugar.uu.net (Peter da Silva) writes:
> In article <1989Feb19.134220.29438 at gpu.utcs.toronto.edu>, woods at gpu.utcs.toronto.edu (Greg Woods) writes:
> > store GMT internally, and for those O/S's that
> > can't manage to relate to the rest of the world, zoo may be compiled
> > with a local time conversion factor built in.
> 
> Because zoo doesn't know what the local time is, but the UNIX system does
> have everythink it needs to convert between GMT and local time. QED.

Let me say that another way:  store file times in zoo archives as GMT.
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 need not know what time
it might be locally.  This time conversion constant would be supplied by
the person who installs zoo on a given system.  It need not be compiled
into the binary, in fact, but may come from an environment variable, a
configuration file, or some other locally convenient place.

Is there anything wrong with creating a Unix-like TZ entity on another
type of system?
-- 
						Greg Woods.

{utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET}
1-416-443-1734 [h], 1-416-595-5425 [w]   LOCATION: Toronto, Ontario, Canada



More information about the Comp.sources.bugs mailing list