JDK-4123961 : (hpi) Need higher resolution System.currentTimeMillis on Win32
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.1,1.1.2,1.1.5,1.2.0,1.2.1
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_95,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-03-30
  • Updated: 2000-02-18
  • Resolved: 2000-02-18
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
IN JDK1.1 and 1.2, System.currentTimeMillis has a resolution of 50ms. This
is too inaccurate for many purposes. Here is a test program:

>  class timeres {
>  
>     public static void main(String args[]) {
>  
>        long t1;
>        long t2;
>        t1 = System.currentTimeMillis();
>        t2 = t1;
>        while (t2==t1)
>           t2 = System.currentTimeMillis();
>        System.out.println("Time difference is "+(t2-t1));
>     }
>  }

Comments
PUBLIC COMMENTS .
10-06-2004

SUGGESTED FIX The following functions are available in kernel32.lib on Windows: QueryPerformanceCounter(LARGE_INTEGER *cnt); QueryPerformanceFrequency(LARGE_INTEGER *freq); and could be used to supplement the system time for higher precision. The timeGetTime() will give up 1ms precision. However, it does not respond to system time adjust. (That is the reason I did not put that in. I am not sure if there is easy workaround.) ###@###.### 1999-07-17
17-07-1999

EVALUATION On Windows NT, the timer accuracy is 10ms. On win95, the timer is 50ms. Though there is a 1ms timer, that is in the winmm.dll (the multimedia kit). And it is not always sync with system timer. ###@###.### 1998-04-16 Will not fix. The real bug is in the specification, which should note that the granularity of the return value is dependent upon the underlying operating A separate bug (4313758) has been filed against the specification. -- mr@eng 2000/2/17
02-08-0183