The test checks that the timestamp of the mouse event accurately represents the current time of the system, even if the time of the system is jumped to the past/future.
On Unix in xawt we calculate the timstamp using this method: reset_time_utc = System.currentTimeMillis() - getCurrentServerTime(); timstamp = reset_time_utc + server_offset; (1.) Note that the "server_offset" - timstamp when the native event was generated, and we try to convert it to the UTC timestamp. Unfortunatly we callculate the "reset_time_utc" only once at the start of the application and then rarely update it. So if the time in the system is changed we still use the old one. The exactly the same bug described at (1.) was fixed on windows by the https://bugs.openjdk.java.net/browse/JDK-6461933 and for that bug the test in question was created. That bug was fixed by the "recalculation" system time more often. But it does not solve the general time issue and the code was reworked again by the https://bugs.openjdk.java.net/browse/JDK-8046495 I would like to fix the current bug in the same was as on windows, see link below: https://bugs.openjdk.java.net/browse/JDK-8046495?focusedCommentId=13517205&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13517205 After the fix we will use the same System.currentTimeMillis()/JVM_CurrentTimeMillis on all platforms. ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=925&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-7194219 Stats: 45 lines in 5 files changed: 0 ins; 38 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/925/head:pull/925 PR: https://git.openjdk.java.net/jdk/pull/925
