# Часы «прыгают» на несколько часов при переключении между Windows и Linux на одной машине: аппаратные часы в UTC или в местном времени, и что выбрать для виртуальных машин

**URL:** <https://kryptos.forum/t/chasy-prygayut-na-neskolko-chasov-pri-pereklyuchenii-mezhdu-windows-i-linux-na-odnoj-mashine-apparatnye-chasy-v-utc-ili-v-mestnom-vremeni-i-chto-vybrat-dlya-virtualnyh-mashin/241>\
**Category:** Виртуальные машины и серверы\
**Tags:** виртуальные-машины\
**Created:** [30.Сентябрь.2026 10:08:33 UTC](https://kryptos.forum/t/chasy-prygayut-na-neskolko-chasov-pri-pereklyuchenii-mezhdu-windows-i-linux-na-odnoj-mashine-apparatnye-chasy-v-utc-ili-v-mestnom-vremeni-i-chto-vybrat-dlya-virtualnyh-mashin/241 "2026-09-30T10:08:33Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![team\_vm](https://kryptos.forum/letter_avatar_proxy/v4/letter/t/779978/32.png) [@team\_vm](https://kryptos.forum/u/team_vm)\
**Post date:** [30.Сентябрь.2026 10:08:33 UTC](https://kryptos.forum/t/chasy-prygayut-na-neskolko-chasov-pri-pereklyuchenii-mezhdu-windows-i-linux-na-odnoj-mashine-apparatnye-chasy-v-utc-ili-v-mestnom-vremeni-i-chto-vybrat-dlya-virtualnyh-mashin/241/1 "2026-09-30T10:08:33Z")

</div>

**Что было.** На машине с двумя системами время после каждой перезагрузки в другую систему уезжает на величину часового пояса. Вопрос: «какое системное время правильное?»

**Почему.** Аппаратные часы (RTC) хранят одно значение без признака пояса. Linux по умолчанию считает, что в них UTC, и вычисляет местное время по настроенному поясу. Windows по умолчанию считает, что в них местное время. Каждая система при загрузке «исправляет» часы под своё представление, и вторая получает сдвиг. Участники сошлись: выбрать один стандарт и применить его к обеим системам; предпочтительно UTC.

**Два способа выровнять.**

1. **Windows → UTC** (рекомендуется): в реестре `HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation` создать `RealTimeIsUniversal` (DWORD) = 1; Linux оставить как есть (`timedatectl` показывает `RTC in local TZ: no`).
2. **Linux → местное время** : `timedatectl set-local-rtc 1`. Система предупредит, что режим не рекомендуется: переходы на летнее время и смена пояса обрабатываются хуже. Годится, если Windows нельзя трогать.  
Автор применил второй вариант и подтвердил, что часы сошлись.

**Что это значит для серверов и виртуальных машин.**

- У виртуальной машины «аппаратные часы» это то, что даёт гипервизор при старте, и по соглашению большинства площадок они в UTC. Гость на Linux работает с этим сразу; гость на Windows при первом старте может показывать время со сдвигом до тех пор, пока не синхронизируется, либо требует `RealTimeIsUniversal`, если гипервизор отдаёт UTC, а Windows ждёт местное. Признак: после каждой перезагрузки Windows-гостя время уезжает на величину пояса и через минуты выравнивается службой времени.
- Правильная конфигурация гостя: пояс задан явно (`timedatectl set-timezone …` / параметры даты и времени), RTC в UTC, синхронизация по NTP или от гипервизора, но не обе сразу.
- Журналы и cron живут в системном поясе; на серверах, которые обслуживают люди из разных поясов, разумно оставить UTC и переводить только при показе (об этом есть отдельный разбор про приложение и системный пояс).

**Проверка на Linux.** `timedatectl` (строки `Time zone`, `RTC in local TZ`, `System clock synchronized`), `hwclock --show` (что реально в RTC). На Windows: `w32tm /tz` и `reg query HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal`.

**Про NTP как «лекарство».** Синхронизация исправляет сдвиг через несколько минут после загрузки, но между загрузкой и синхронизацией службы стартуют с неверным временем: ошибки TLS, неверные метки в журналах, сбитые задачи планировщика. Выровнять RTC надо, а не надеяться на NTP.

Команда описана в [документации systemd](https://www.freedesktop.org/software/systemd/man/latest/timedatectl.html).