The proposed change for 8015666 is supposed to stop this test failure. But as I
said
last time that it may take a while for it to get into the repo. I will start
the CCC process
shortly, if there is no objection.
-Sherman
On 06/25/2013 12:27 PM, Eric McCorkle wrote:
Does the fix for 8015666 stop the error from happening? If so, then
I'll withdraw this RFR.
On 06/25/13 13:50, Xueming Shen wrote:
This is fine to be a workaround for the test case for now. It probably
will need to be
undo-ed after the propose change for #8015666 get integrated.
http://cr.openjdk.java.net/~sherman/8015666/webrev/
The proposal for #8015666 is to keep the "existing" behavior of
ZipEntry.getTime()
to return a LastModifiedTime converted from the zip entry's
ms-dos-formatted date/time
field by using the "default" timezone. A new pair
ZipEntry.get/setLastModifiedTime()
will be added to access the "real" UTC time stored in the zip entry, if
presents.
The API doc will be updated accordingly as well to explicitly explain
the source of the
date/time and the its timezone sensitive conversion.
-Sherman
On 06/25/2013 07:03 AM, Eric McCorkle wrote:
Hello,
Please review this simple patch which updates regression test
langtools/tools/javac/T6725036.java to offset the time returned by
JavaFileObject.getLastModified() with the local time to UTC delta.
Please note that this patch is intended to address the test failures,
and that I will be immediately opening a new bug to investigate and
address deeper issues, and also to properly document the API.
The webrev is here:
http://cr.openjdk.java.net/~emc/8016760/
The bug report is here:
http://bugs.sun.com/view_bug.do?bug_id=8016760
Thanks,
Eric