Ух ты, какой топик!
Я вот тут спрашивал http://www.sql.ru/forum/1163981/cekunda-koordinacii-kak-ee-pravilno-nastroit-v-ntp когда напоролся на подобное. У меня это привело к тому, что UTC скаканули на 1сек назад. Те часы, значение которых читаю через System.currentTimemillis().

Как это нормально лечить (кроме своей обертки вокруг System.currentTimemillis) - я до сих пор не знаю.

Помимо того, что написано в том топике, я узнал следующее. System.nanoTime() должен давать по факту монотонное время на системах, которые поддерживают монотонность, хотя стандартом монотонность вроде как не обещается(?).

Есть так же либа time4j, в которой судя по сравнительной таблице http://www.time4j.net/tutorial/appendix.html обещается, что есть monotonic clock.

Несколько лет назад был баг в mysql и в ядре, и когда пришла очередная leap second то эти два бага наложились друг на друга и это приводило к 100% загрузке одного ядра. Лечилось перезапуском mysqld. Потом этот баг починили.

вообще, на разных компах часы по-разному организованы, и есть разные таймеры(например у меня - tsc hpet acpi_pm ). Посмотреть таймеры можно командами
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Наиболее хороший это hpet и если он есть - насколько понимаю, использовать желательно его, причем линукс не всегда выбирает его по умолчанию - поэтому надо ядру ключиком это указывать.

Когда-то помню, на старой машине, последовательные System.currentTimemillis давали иногда отрицательную разницу - видимо, изза плохого таймера, найти причину не удалось, т.к. проявлялось это редко. Еще в каждом ядре есть счетчик тиков, и бывает такое, что то ли линукс то ли java почему-то использует его, в этом случае значения этого счетчика могут зависеть о того, на каком ядре сейчас исполняется поток. С этим моментом я пока нормально не разобрался.

Насколько могу судить, когда leap second двигает часы назад, то пул Executors.newSingleThreadScheduledExecutor не уменьшает и не увеличивает следующий запуск задачи. Т.е., если например задано, что надо запускать с периодом 10сек, то оно с таким периодом и будет запускаться, назвисимо от того, куда ntpd вздумает резко перевести время.

Basil A. SidorovВисокосная секунда не переводит часы назад: либо вставляется шестидесятая секунда либо повторяется пятьдесят девятая. Всё остальное баги софта. В вашем случае, вероятно, ошибка возникала из-за смешивания двух разных вещей - интервала и времени.

Это лишь значит, что у вас свое понимание термина "часы" и понятия "перевод назад".
Повтор секунды, это есть перевод назад, особенно если приложение оперирует миллисекундами.
Кстати, високосных секунд может быть несколько, есличто. Пока в истории такого не было, но со временем это будет.
В моем случае последовательные чтения System.currentTimemillis в одном потоке дали обратных ход часов. В милисекундах это перевод назад, в юникстайме это повтор той же секунды. Это как по-вашему? Перевод назад или не перевод? Или utc-это не часы а счетчик, по-вашему?