VMS Unzip doesn't adjust for GMT

[Hoff]

>Could you please elaborate on the "time zone fiddling" suggestion?

I read that to have been a comment indicating that it appeared likely that two Unix boxes could be configured to encounter the same md5 mismatch; that the same issue being chasing here between the Unix box and the OpenVMS box appears possible between two Unix boxes. That the same md5 checksum mismatches can arise between two Unix systems and without OpenVMS involved here. That the md5 mismatches can arise between most any systems due to differences in the timekeeping settings between arbitrary systems.

And it could well be possible to see this md5 stuff get stomped on OpenVMS due to a DST switch-over, for instance.

[Steven Schweda]

> Could you please elaborate on the "time
> zone fiddling" suggestion?

Hey. It wasn't _my_ idea. You started it:

Nov 20, 2009 19:26:34 GMT
> [...]
> On Unix, it is possible to get the proper
> timestamp back by setting TZ
> variable before calling unzip. [...]

What I don't understand is this:

Nov 21, 2009 02:49:26 GMT
> The zip files don't match unless the extra
> timestamp info is stripped.

My claim (subject to contrary evidence) is
that if you're on a UNIX(-like) system, then
the UTC date-time data stored in a Zip
archive should always be the same, so if,
when you _create_ the archive, you fiddle
with the time zone to get the local times to
match, then all the date-time data in the
archive should match. I don't see what
stripping out the UTC data buys you (other
than trouble, when you unpack the stuff on a
VMS system).

I think that you should be able to:

1. Create a (tiny test) archive in Europe,
on a UNIX(-like) system, without using "-X".

2. Ship it to the US, and extract the files
on a UNIX(-like) system.

3. Re-create the archive in the US, on a
UNIX(-like) system, using the same Zip
version, from those extracted files, but with
an artificially European time-zone setting.

I don't see why the date-time data in this
re-created archive should differ from those
in the original archive. Show me actual
data to persuade me otherwise.

An interesting problem arises involving the
date-time data for directories. Currently,
UnZip will restore the date-time for a
directory, even though the new directory is
actually created anew, not restored from a
directory which was stored in the archive.
Consider, for example, a case where only some
of the files in a directory are stored in an
archive. When this archive is expanded, the
re-created directory will have contents which
differ from those of the original directory,
so it makes little sense for the date-time of
the re-created directory to match that of the
original directory. (I'm trying to persuade
the UnZip maintainer to add an option to fix
this, but it's not in there yet.) Note that
VMS BACKUP (not /IMAGE) gives you new-looking
directories, not date-time-restored
directories, which makes more sense than the
current behavior of UnZip (or, I believe,
"tar").


Now, there are many other data in a Zip
archive which might cause trouble in a
situation like this. The Zip archive format
is described here:

http://www.pkware.com/documents/casestudies/APPNOTE.TXT

and it includes many things related to the
host system type, the file system type, the
Zip program version, file ownership and
permissions, and so on, but these could be
controlled, probably adequately.

That said, basing such a data integrity check
on the potentially volatile fine print in a
Zip archive would probably not be my choice.
Nothing particularly superior is leaping to
mind, however.

[Willem Grooters]

Stupid idea, perhaps:

If you zip /unzip on either side of the big pond on systems that have the SAME timezone (UTC, GMT, CET, WCT - whatever), just for distribution: would that not bypass the whole problem?

[Steven Schweda]

> [...[ would that not bypass the whole
> problem?

I claim that it would solve it, assuming
UNIX(-like) systems, which are based on UTC.
I'm waiting for some evidence to the
contrary.

If you have a VMS system where local time
equals UTC, then I'd expect it to match a
UNIX(-like) system with a UTC time-zone, too,
but that's a more restrictive set of
requirements.