I've been digging into some odd behavior that ultimately traced back to periodic changes to Windows system clock. After doing some research, I've found that:

• Sun's JVM (through 1.6) has a bug that pushes the system clock into the future faster than real-time.
• I've observed clock drift by as much as 3 minutes in 1 hour
• there's no single trigger that your code can do (or avoid), it seems many people have observed the clock drift in different scenarios
• the bug is still open in Sun's bug database: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6435126
• as of June 2006, they're targetting Java 7 for a fix, and as of March 2009 the bug is still open
• this affects Windows only, and the underlying cause is ultimately something screwy with clocks and timers on Windows

The Sun-recommended workaround -- as documented here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6435126 -- is to create a zombie thread at JVM startup. This has the effect of fixing the clock drift issue on Windows, not sure if this needs to be excluded/ignored if you have a multi-platform product, but it should be pretty straightforward to do an OS check and ignore if OS != Windows.

new Thread() {
	{ this.setDaemon(true); this.start(); }
	public void run() {
		while (true) {
			try {
				Thread.sleep(Integer.MAX_VALUE);
			} catch (InterruptedException ex) {
			}
		}
	}
};