FULL PRODUCT VERSION :
At least:
- java version "1.6.0_07", Java(TM) SE Runtime Environment (build 1.6.0_07-b06), Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
- java version "1.6.0_10", Java(TM) SE Runtime Environment (build 1.6.0_10-b33), Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
At least:
- Microsoft Windows XP [version 5.1.2600]
- Linux 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
When a system time change occurs (user update, NTP synchronization...), active Swing timers may behave inappropriately: their actions are triggered either too early, too late, or -worse- never.

It's probably due to the fact that Swing timers rely on system (wall-clock) time to sample current time, i.e. by calling java.lang.System.currentTimeMillis(). When the system time change occurs between 2 calls to currentTimeMillis(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.

In order to make Swing timers resistant to system time updates, they should use the process time, i.e. by calling java.lang.System.nanoTime() -multiplied by the appropriate factor, of course.

Thanks a lot,
Regis.


REPRODUCIBILITY :
This bug can be reproduced often.