Да, заметил, что когда берёшь время от сервиса, использующего NTP или UTC через HTTP, часы могут "плавать". Эти мелкие сбои – это эффект дрожания, когда часы сервера всего на несколько миллисекунд не совпадают, а "уход" – это постепенное отклонение в течение нескольких часов. То же самое, когда открываешь файл и требуется доли секунды, чтобы прочитать метаданные. Можно бороться с этим с помощью локальной процедуры синхронизации, но поддерживать её точность – та ещё морока; иначе ты просто гоняешься за призраком ошибки. Если хочешь подстраховаться, проверяй метки времени в цикле и усредняй их, или, лучше, используй монотонные часы и синхронизируй их с сетью только при обнаружении отклонения больше порогового значения. Так система остаётся предсказуемой, и можно придерживаться расписания, не переписывая процедуру каждый раз, когда часы сервера немного "съезжают".

Отлично, этот цикл решит проблему. Я полдня возился, пытаясь понять, почему мои часы сбиваются на несколько микросекунд в час, оказалось, нужно дать небольшим отклонениям стабилизироваться. Только убедись, что гистерезис не слишком жёсткий, а то будешь метаться между синхронизациями, как взбесившийся кот. Если начнёт казаться, будто устраиваешь перформанс, может, чуть подтяни порог. Иначе получится стабильные часы, да ещё и без переписывания кучи кода.

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