Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!mhres!jv
From: jv@mhres.mh.nl (Johan Vromans)
Newsgroups: comp.sources.bugs
Subject: Re: File times (was: Zoo and Timezones)
Message-ID: <2888@mhres.mh.nl>
Date: 17 Feb 89 08:43:35 GMT
References: <13152@steinmetz.ge.com>
Organization: Multihouse NV, the Netherlands
Lines: 48

From article <13152@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr):
} In article <2884@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes:
} | A file created at 12:00 GMT will have its time stamped 12:00 GMT
} | whatever timezone it was created, archived or extracted.
} | File times are stored internally relative to GMT. When stored
} | this way, they should be retrieved this way. No need to change it.
} 
}   I don't understand this comment at all. Files are stored internally
} *where* as GMT? The only o/s which does this (as far as I know) is UNIX,
} and zoo runs on seven other o/s flavors.

Incorporating timezones always yields problems like these.
You can store the local time of a file, and restore it to local
time. Or you can incorporate timezones and adjust the local time
to a uniform timeframe (e.g. GMT). SInce most systems do not know
about timezones (e.g. MSDOS, VMS), it were better for a real
good exchangeable archiving program like zoo to ignore timezones,
store local times only, and document that it is done this way.

From article <5746@bsu-cs.UUCP>, by dhesi@bsu-cs.UUCP (Rahul Dhesi):
} The intent was to have all timezones represented as seconds west of
} GMT, up to a maximum of 24*60*60 seconds.  So if you are 1 hour east of
} GMT, you are also 23 hours west of GMT.  If there is a bug related to
} this, it probably involves a missing 1-day adjustment for sites east of
} GMT and west of the International Date Line.

Yes it does. +23 hours is not equivalent to -1 hour, it differs
one day.

} >File times [should be] stored internally relative to GMT.  When stored
} >this way, they should be retrieved this way. No need to change it.
} 
} The main problem with doing this is that not all operating systems
} maintain information about where they are relative to GMT.  Most users
} don't even *know* how far they are from GMT.

I would suggest the following:

 a. allow for timezones east of GMT. The way the information is
    currently stored is ok, but it needs to be interpreted as a
    signed character instead.

 b. add a command line option to have zoo ignore timezone
    information (as if it were compiled without GETTZ).
-- 
Johan Vromans			 jv@mh.nl via european backbone (mcvax)
Multihouse [A-Za-z ]* [NB]V			uucp: ..!mcvax!mh.nl!jv
Gouda - The Netherlands				  phone: +31 1820 62944