Flame: Problem with zoo: restoring times

[Tom Neff]

Peter da Silva's solution is best.  ZOO should store local times plus a
timezone offset so that smart OS's like UNIX can convert to GMT for the
internal file timestamp.  Even systems like MS-DOS which store times
locally, but which allow you to set TZ in your environment, would find
this useful, since ZOO could convert from Pacific time (for instance)
to MET when a European DOS user unpacks something assembled in the
Golden State.

A point I'm not sure has been clearly made here is that the status quo
is *wrong* even in the MS-DOS world by itself.  When I unpack two ZOOs
dated the same day, I don't actually know which of the two is newer;
all I know is where Mickey's hands were on the wristwatch of each
author at the moment he built his file.  This becomes troublesome
when data is exchanged electronically worldwide, which is of course
exactly one of ZOO's big justifications.  Rahul went all out to conquer
stuff like filename syntax: this time thing ought to be a snap.

The other objection of the original poster is 100% correct.  Offset
from GMT needs to be a signed quantity.  Greenwich is not located at
the zero point of the world's day, but rather in the exact center!  The
zero point is the International Date Line.  Europe is most emphatically
*not* 23, 22 and 21 hours "behind" Greenwich; it is 1, 2, and 3 hours
*ahead*.  (No place on Earth is more than 12 hours behind Greenwich.)
It should be trivial to make an upward compatible change to ZOO to
support the time offset as a signed quantity.  Old "+23h" formats
would be silently translated to the new format.

ZOO is doing terrifically well as the binary archiver of choice on a
wide variety of platforms.  The above is meant purely as constructive
criticism!
-- 
Tom Neff                  tneff at well.UUCP
                       or tneff at dasys1.UUCP