Please do; this test has been failing for almost a month now.
On 06/25/13 15:45, Xueming Shen wrote: > 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 >
