EVALUATION

The problem could be uncovered by looking on awt_Component.updateBootTimeUTC() function which tries to calculate the number of millis that have elapsed since system was started. For that purpose it gets currentTime(millis since 1601) and getTickCount()(millis since boot) and calculates a number of millis since 1970 till system start.
The trick is, boot_time_1601 variable changes rather often in the range +-1 if we use that updateBootTimeUTC() function(now it's under if statement and called rarely). Sometimes the value changes by +-10 millis.
So far if we use updateBootTimeUTC() for every message then the defect goes away. That happens because of that +-1 millis correction. We probably do not use this update yet because of performance issues(is this still an issue though?).
                                     

SUGGESTED FIX

http://sa.sfbay.sun.com/projects/awt_data/7/6451578/
                                     

EVALUATION

I verified that the time obtained by JVM_CurrentTimeMillis() method (native method for System.currentTimeMillis()) and nowMillisUTC() may differ. In my environment I haven't seen more the one ms shift. The best approach that comes in mind is to use the same way as JVM when obtaining system time.
                                     

EVALUATION

Seem there is a inaccurancy when we calcalating a time when native message happen.
awt_Component.nowMillisUTC(DWORD event_offset)
takes a message_offset (relative to sys epoch) and is trying to convert it into UTC. But it uses GetTickCount() and GetSystemTime() for further calculations.
I verified that
                                     

EVALUATION

This bug can be easily reproduced at least with 1.5, so this is not a regression. AWT event's field 'when' is calculated in nowMillisUTC() function defined in awt_Component.cpp. It seems that this function uses another native API (or uses it in another way) than System.currentTimeMillis().