Hi Sherman,
Sorry for the delay, that looks fine.
If zip is still around that far in the future, everyone will have the
same problem.
Roger
On 7/17/2015 12:12 PM, Xueming Shen wrote:
On 7/17/15 8:45 AM, Xueming Shen wrote:
On 7/17/15 1:04 AM, Peter Levart wrote:
Hi Sherman,
On 07/15/2015 09:10 PM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8130914.
issue: https://bugs.openjdk.java.net/browse/JDK-8130914
webrev: http://cr.openjdk.java.net/~sherman/8130914/
This is a "regression" triggered by
https://bugs.openjdk.java.net/browse/JDK-8130914
http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
And-ing the result with a 32 bit mask (2^32 - 1) does make sure that
high 32 bits are not touched by year encoding. As I understand, this
starts to be a problem with year 2044 and beyond when (year - 1980)
<< 25 becomes a negative number. Expanding it to long sets the high
32 bits too. If we treat the lower 32 bits as unsigned, we
accommodate for years up to and including 2107. At 2108, the
overflow happens and decoding the year back gives 1980 instead of
2108. So I wonder:
- will there be a DOS compatible ZIP format after 2108 ?
- will there be Java after 2108 ?
Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like
the unix time has a 2038 ceiling if
the long stays as 32-bit.
- depending on the above answers, should there be a
DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the
date is clamped?
btw, we do have a ZipEntry.UPPER_DOSTIME_BOUND to help save a
timestamp into the extra field, if necessary.
-sherman
