Что должен делать Timertask.scheduleAtFixedRate, если часы меняются?

Глядя на источник Timer для Java 1.7, кажется, что он использует System.currentTimeMillis() для определения следующего выполнения задачи.

Однако, если посмотреть на источник ScheduledThreadPoolExecutor, он использует System.nanoTime().

Это означает, что вы не увидите такого поведения, если используете его вместо Timer. Для его создания используйте, например, Executors.newScheduledThreadPool().

Почему вы не видите такого поведения, потому что в документе для System.nanoTime() написано:

Этот метод может использоваться только для измерения прошедшего времени и не связан с каким-либо другим понятием системного времени или времени настенных часов. Возвращаемое значение представляет собой наносекунды с некоторого фиксированного, но произвольного времени происхождения [выделено мной].

Что касается того, ошибка ли это в Timer, может быть ...

Обратите внимание, что в отличие от ScheduledExecutorService, Timer поддерживает абсолютное время, и, возможно, этим объясняется использование System.currentTimeMillis(); кроме того, Timer присутствует с Java 1.3, а System.nanoTime() появляется только в 1.5.

Но следствием использования System.currentTimeMillis() является то, что Timer чувствительно к системной дате / времени ... И это не задокументировано в javadoc.

Об этом сообщается здесь http://bugs.sun.com/view_bug.do?bug_id=4290274

Точно так же, когда системные часы установлены на более позднее время, задача может выполняться несколько раз без какой-либо задержки, чтобы «наверстать упущенное». Именно это происходит, когда компьютер находится в ждущем / спящем режиме и приложение возобновляет работу (вот как я узнал).

Это поведение также можно увидеть в отладчике Java, приостановив поток таймера и возобновив его.