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

Volker Halle wrote:

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.



.