Re: [VMS V7.3-2] ECO date
- From: Hoff Hoffman <hoff-remove-this@xxxxxx>
- Date: Wed, 06 Sep 2006 14:45:42 -0400
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.