Установка часов Windows XP неправильно после резюме от сна

Мое предположение - то, что Windows так или иначе неправильно себя ведет на пробуждение от сна относительно системного времени. В соответствии со статьей Wikipedia ключ реестра, который Вы цитируете, не полностью работает, даже на последних версиях Windows:

Windows ожидает, что часы реального времени компьютера будут работать на местном времени. Так как Windows NT там был ключом реестра RealTimeIsUniversal=1, но эта функция не поддерживается или полностью реализуется все же (включая Vista), таким образом, не возможно выполнить часы реального времени на Всемирном координированном времени.

Я думаю, что Ваш лучший выбор здесь состоял бы в том, чтобы сказать Linux, что системные выполнения часов в местное время и стиснули зубы два раза в год с DST.

ETA: Эта статья детализирует проблему немного больше и также подсказывает на том, что проблемы с тем ключом реестра устраняются в Vista SP2 и Windows 7:

2001-07-09: Я получил ответ от кого-то в Основной Команде Ядра Microsoft, которая была заинтересована RealTimeIsUniversal, и они взглянули на соответствующие части исходного кода ядра NT. Флаг RealTimeIsUniversal там (остаток со дней, когда NT все еще работал на машинах RISC с UTC RTCs), но его реализация кажется теперь неполной, и он в настоящее время не охватывается документацией Microsoft и пакетом регрессионного теста, поэтому с помощью него не рекомендуется в это время. Несколько потенциальных ошибок RealTimeIsUniversal были определены за прошедшие несколько дней, могло бы быть больше. Например, отладчик ядра предполагает, что время CMOS является местным временем и поймет время превратно когда RealTimeIsUniversal=1. Могла бы быть подобная проблема в коде, который продолжает обрабатывать после того, как ЦП был приостановлен или в коде, который вычисляет времена изменения DST.

2008-10-31: Ура! Кто-то от Базового Подразделения Операционных систем Microsoft подсказки в электронном письме мне, что и Vista SP2 и Windows 7 решат проблемы в поддержке RealTimeIsUniversal=1, которые сделали выполнение часов CMOS в UTC до сих пор не практичным с Windows (т.е. время неправильно после возобновлялось, приостанавливал/был в спящем режиме Windows). Он предупреждает, хотя та эта улучшенная поддержка UTC в часах CMOS не может сразу быть широко зарегистрирована, и детали могут измениться в будущем.

Так, завершение, я думаю, что у Вас есть две опции:

1. Обновите до недавней ОС.
2. Переключите Linux на местное время.

P.S.: Вопреки другим плакатам здесь, это не может быть батареей CMOS. Часы реального времени не приводятся в действие батареей, пока система имеет силу. Это включает режим ожидания (очевидно). В случае, если батарея CMOS неисправна, часы реального времени сбросили бы себя к своим заводским настройкам, который является обычно 1 января несколькими годами назад. Смещения нескольких часов просто не происходит, поскольку нет никаких часов "состояния", которое переживает полные потери мощности. Это не сродни настенные часы с облупленной батареей, которая сохраняет ее время, даже когда батарея неисправна.

Если время корректно, когда Вы загружаетесь (потому что оно синхронизируется), и корректно, пока Windows там для усовершенствования его, но не совершенствуется, когда Windows спит, то по всей вероятности необходимо проверить батарею CMOS.

Это не походит на батарею CMOS, поскольку это обычно сбрасывает время на установленную дату вместо того, чтобы быть "от нескольких часов".

Другое временное решение состоит в том, чтобы установить что-то как Синхронизация Атомных часов и установить ее на "Auto Synchronize Daily". Это заставит часы подчиняться назад.