On 02/26/2015 01:17 AM, Claes Redestad wrote:
We could preserve precision by shifting the remaining milliseconds
into the dostime field,
since the DOS time will only use the 4 lower bytes:
http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/
After I went through more extensive testing and verification I
realized that narrowing
dostime to an int and breaking this remainder hack out into a separate
field would be
possible without affecting ZipEntry footprint; arguably cleaner, but
if this version is
acceptable I would prefer not to.
Going this way preserves precision across the entire input range of
setTime, thus all tests
I could find pass with this version; I've also expanded the
TestExtraTime test to test both
far ancient, far future and near future times to verify precision is
preserved.
I backpedaled on the getLastModifiedTime optimization to set the mtime
field that Peter
suggested since it would have the side-effect that the extra time
field would be written
after a call to this getter, which would be a bit too unexpected.
Thanks!
/Claes
Hi Claes,
I like the backwards-compatible extended DOS time format idea. If you
keep it as one field, you could move the code for conversion from
millisecond Java time to/from extended DOS time format to the ZipUtils
methods entirely (javaToXdosTime, xdosToJavaTime) to make logic in
ZipEntry simpler. I would call the field 'xdostime' then to hint the
reader about the format which would be nice if it was described in a
javadoc on the field.
Regards, Peter
