🚀 go-pugleaf

In article <2880@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes:
>Length    CF  Size Now  Date      Time
>--------  --- --------  --------- --------
>       0   0%        0  13 Feb 89 19:49:24+64   xxx.tmp
                                           ^^^
The file is being stored in the archive with its timezone 64 hours west
of where you are.  At extraction time zoo adjusts the time for the
timezone, yielding a wrong timestamp.  (Since the zoo code was not
designed to handle timezones larger than 24 hours away, this may cause
other overflow problems somewhere.)

EMERGENCY WORK-AROUND

Undefine the GETTZ symbol with "#undef GETTZ" at the end of the file
options.h, delete all object files, and recompile the whole thing.  Zoo
will no longer save, list, or restore timezones.  Local times will be
still fine, but an archive moved to a different timezone will still
show the original local time.

BUG FIX STRATEGY

The code that stores the timezone into the archive is in function
newdir() in file zooadd2.c:

   long gettz();
   direntry->tz = (uchar) (gettz() / (15 * 60)); /* seconds => 15-min units */

The gettz() function, found in bsd.c and sysv.c, must return the
timezone, in seconds west of GMT, as a long value.  The above code
scales this value to to 15-minute units, casts the result to unsigned
char (which is typedef'd as uchar), and assigns it to direntry->tz.

So I suggest:  (a) confirm that gettz() is working on your system as
implemented in bsd.c or sysv.c;  (b) confirm that the value assigned to
direntry->tz is your timezone, in 15-min units, west of GMT.

If the above works, then the problem is in the extract/list code, which
is incorrectly interpreting the stored timezone value.  More about that
in private email if necessary.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
                    ARPA:  bsu-cs!dhesi@iuvax.cs.indiana.edu