Re: [VMS V7.3-2] ECO date

The dat[e] is clearly wrong ! I would guess, that the .33 after the
seconds may just be some local time value, if the date stored in the
self-compressing image did not include the full OpenVMS time value.

I'd not immediately tend to assume zip includes the hundredths -- there are
various ways to get drift in the lowest bits of the quadword, not the least of
which is via DECnet FAL.

zip (and unzip) may well be using a Unix-format date value -- yep, just
looked, it's converting into and out of the epoch. And the Unix epoch doesn't
have particular precision. I have NOT confirmed it is the conversion at fault
here, nor at whether or not the FDL approach ("-V") avoids this path; this has
not been confirmed.

Short of a change to (at least) unzip/unzipsfx (and assuming FDL isn't a
work-around) (and pending confirmation), this will likely be the behaviour seen
at least for the near-term, for better or for worse.

--

I've commented before around the whole ECO process, and blogged on it once or
twice -- but I don't see the current processing sequence and the environment
changing particularly soon.