Hi Max,
On 2019/3/18 22:04, Weijun Wang wrote:
Hi John,
The new webrev looks mostly fine, except that I don't like the new lambda in
Test.java. But I'll leave it to you to decide if that style is good.
Have you been able to reproduce the original test failure and make sure your
updated test passes in the same environment? Otherwise, I cannot be sure if the
fix is at the right spot.
I had reproduced this issue. It only raised at the midnight.
The cause is what I mentioned on "-J-Duser.timezone=null".
The test passed with my fix.
Best regards,
John Jiang
Thanks,
Max
On Mar 18, 2019, at 8:28 PM, sha.ji...@oracle.com wrote:
Hi Max,
If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone
GMT-8/PST, but not the local timezone.
Currently, the testing machines should use GMT-7/PDT.
If no user.timezone is specified, jarsigner just uses local timezone.
Please review the updated webrev:
http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/
It doesn't specify user.timezone for jarsigner if this property is null, and
still makes sure jarsigner and date formatter use the same timezone.
Best regards,
John Jiang
On 2019/3/14 09:52, Weijun Wang wrote:
On Mar 13, 2019, at 4:58 PM, sha.ji...@oracle.com wrote:
Hi,
This fix just makes sure that specified timezone is not null,
Or maybe if it's null then shall we also not pass it to the tools? If I understand
correctly, by doing this we also test the default timezone case, which I believe is more
common. (At least I don't see it in "java -XshowSettings:properties" on my
laptop).
BTW, are you able to reproduce the failure by faking the time? All failures
happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z.
--Max
and the jar verifying and date formatting use the same different timezone.
Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
Best regards,
John Jiang
