>[оверквотинг удален]
> А какие есть решения без шины? Без шины неизвестно кто заинтересован в
> событии. Ну не рестартовать же вообще все программы? Ну вот и
> начинаются чудеса после перевода часов - там бабахнуло, тут пиротехника, там
> что-то заскрипело, вон в том углу стремно скрежещет что-то и кислота
> течет. А вон там вообще программа наглухо висит, ибо она ждала
> now + 5 sec, а какой-нить демон NTP дорвался до сети
> и наконец выставил правильное время, в эти 5 секунд как рах.
> Ну там now - 100500 часов, например. И будет прога ждать
> 100500 часов и 5 секунд вместо 5 секунд. Что с точки
> зрения юзера эквивалентно взвису, т.к. "немного" отличается от 5-секундной паузы.

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

в юниксе "внезапный перевод часов" бывает только в одном случае - при запуске системы, у которой нафиг села батарейка RTC и требуется синхронизация времени. Больше в юниксе часы "внезапно" не переводятся. На системах, где лень настраивать NTP, время может регулярно подводиться раз в день, но перевод времени NTP не влияет на clock_gettime, как тут уже заметили ниже.

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

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