Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4210664

Thread.sleep behaves erratically if system time is changed



    • Subcomponent:
    • CPU:
      x86, sparc
    • OS:
      solaris_2.5.1, windows_nt


      Name: dbT83986 Date: 02/10/99

      I have a piece of code that sits in a for loop, sleeps for 2
      seconds, wakes up and does something (prints "I'm back" in the code
      snippet below):



              Normally, this code runs as expected, i.e. it waits for
      2 seconds, and prints I'm back, ad infinitum. However, if I
      change the system time while this code is running, it exhibits
      the following erratic behavior:

      - If the current time is 12:15:00 and I change the time to 11:15:00
        the Thread.sleep (2000) does not wake up for the next one hour + 2
        seconds, which is incorrect.

      - If the current time is 12:15:00 and I change the time to 13:15:00,
        the Thread.sleep (2000) works correctly, i.e. wakes up after 2

      java.lang.Object wait exhibits an identical erratic behavior.
      I tried a similar C program, and this problem was not seen,
      i.e. the sleep wakes up after the specified interval regardless
      of system time changes. Here's the C program:

      #include <stdio.h>

      int main()
        int i = 0;

        while(1) {
          printf("%d: I'm back\n", i++);
      In the presence of this bug, our Java server system hangs when the
      system time changes (e.g. during daylight savings time change).

      I was wondering if anyone can provide insight into this problem. It
      looks like Thread.sleep is behaving as though it cared about the
      absolute time, rather than the relative time. If anyone can suggest a
      workaround, that would be very helpful to me.


      (Review ID: 52515)

      1999-12-08: NOTE: a daylight savings time change does
      NOT affect gettimeofday(), which uses universal coordinated time (UCT).
      Thus, the bug can only arise when system time is abruptly changed.
      Changing the system time abruptly is not recommended on enterprise
      systems (for instance those running on clusters). Rather adjtime()
      should be used to "drift" the time to the right value.
      Without further justification as to why the customer wants to abruptly
      change time on a running Solaris system, this "bug" will not be fixed.


          Issue Links



              collins Gary Collins (Inactive)
              dblairsunw Dave Blair (Inactive)
              0 Vote for this issue
              0 Start watching this issue