jv@mhres.mh.nl (Johan Vromans) (02/17/89)
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
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/19/89)
In article <2888@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes:
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.
My feeling exactly, which is why the default action, in the absence of
the symbol GETTZ being defined, is to do the above. I quote from the
zoo manual:
The file time listed is, however, always the original
timestamp of the archived file, as observed by the user who
archived the file, expressed as that user's local time.
(Timezone information is stored and displayed only if the
underlying operating system knows about timezones.)
I'll keep the other major suggestion (maintain timezone as a signed
number) in mind.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu