Компьютеры · Инструкция
WSL показывает неправильный часовой пояс: как синхронизировать с Windows
Если WSL показывает неправильный часовой пояс, сначала проверьте настройку синхронизации зоны с Windows, а не меняйте.
Короткий ответ
Как исправить неверный часовой пояс в WSL через [time] useWindowsTimezone, правильно перезапустить WSL и отличить timezone от сбоя часов.
Сначала отличите часовой пояс от неправильного времени
Выполните внутри WSL `date` и `timedatectl` (если он доступен в вашем дистрибутиве). Сравните не только часы, но и обозначение зоны/смещение UTC. Если UTC-время корректно, а локальное время сдвинуто ровно на один или несколько часов, вероятнее проблема именно в timezone. Если ошибается и UTC, речь уже не только о зоне, и параметр `useWindowsTimezone` не следует считать универсальным ремонтом часов. Затем проверьте часовой пояс в Windows: WSL не может правильно «наследовать» настройку, если сама Windows выставлена неверно. Полезно также зафиксировать вывод `wsl --version`, потому что настройки времени развиваются вместе с WSL.
Предупреждение: Не лечите сдвиг зоны командой, которая просто вручную переводит часы Linux. После перезапуска вы получите новый рассинхрон или двойную коррекцию.
Как включить использование часового пояса Windows
- 1. В нужном дистрибутиве откройте `/etc/wsl.conf` с правами root. 2. Добавьте секцию `[time]`. 3. Укажите `useWindowsTimezone=true`. Это значение и так является стандартным, но явная запись полезна, если конфигурация раньше менялась. 4. Сохраните файл. 5. В PowerShell выполните `wsl --shutdown`. 6. Запустите дистрибутив снова и повторите `date`. 7. Если локальное время всё ещё неверно, перепроверьте Windows Settings → Time & language → Date & time и затем снова перезапустите WSL.
Важно: Изменения `/etc/wsl.conf` применяются при новом старте дистрибутива. Полный `wsl --shutdown` исключает тестирование старой конфигурации.
Что делает useWindowsTimezone и чего не делает
Параметр отвечает именно за использование и синхронизацию часового пояса, заданного Windows. Он не заменяет NTP-клиент, не исправляет любую ошибку системных часов и не обязан решать проблемы стороннего контейнера со своей timezone-базой. В контейнерах Docker локальное время может определяться отдельными настройками образа; Java, Node.js и базы данных тоже иногда используют собственные TZ-данные или переменные окружения. Поэтому после исправления `date` в самом WSL проверяйте проблемное приложение отдельно. Если только приложение продолжает показывать старую зону, WSL уже может быть настроен правильно, а причина лежит выше — в `TZ`, конфигурации процесса или устаревшем tzdata.
Где искать источник сдвига
- Windows показывает неверную зону | Исправить зону в Windows | WSL наследует неверную базовую настройку
- `date` в WSL неверен, Windows верна | Проверить `[time] useWindowsTimezone=true`, перезапустить WSL | Уровень WSL
- `date` верен, контейнер неверен | Проверить timezone/TZ внутри контейнера | Уровень контейнера
- `date` верен, приложение неверно | Проверить настройки приложения и tzdata | Уровень приложения
- Ошибается UTC, а не только локальное смещение | Искать проблему синхронизации часов, не только timezone | Другой класс неисправности
Совет: Проверяйте слои сверху вниз: Windows → WSL → контейнер → приложение. Так вы не меняете четыре настройки ради одной ошибки.
Почему настройка может снова «сломаться»
Явный `useWindowsTimezone=false` в старом `/etc/wsl.conf` переживает обновления и продолжает отключать наследование зоны. Ещё один вариант — корпоративный скрипт или dotfiles-проект перезаписывает конфигурацию дистрибутива. Если вы работаете на ноутбуке и часто меняете страны, проверьте, обновляется ли зона именно в Windows после подключения к сети; WSL будет ориентироваться на эту сторону. Не путайте название зоны и числовое смещение: переход на летнее время может менять UTC-offset при том же регионе. Если вы вручную правили `/etc/localtime`, зафиксируйте это как отдельное изменение и по возможности верните систему к одному источнику правды, чтобы Windows и Linux не спорили между собой.
Проверка результата
- часовой пояс Windows корректен
- `/etc/wsl.conf` не содержит `useWindowsTimezone=false` без необходимости
- после правки выполнен `wsl --shutdown`
- `date` в WSL показывает ожидаемое локальное время и смещение
- приложение проверено отдельно, если только оно показывает другую зону
Переезд между часовыми поясами и летнее время
После поездки или смены региона сначала меняйте часовой пояс в Windows, а уже затем перезапускайте WSL. С включённым `useWindowsTimezone=true` дистрибутив должен подхватить системную зону Windows; для чистой проверки выполните `wsl --shutdown`, снова откройте Linux и сравните `date`, `date -u` и текущее смещение. Не подменяйте региональную зону фиксированным `UTC+2` или похожим смещением, если вам важно летнее время: правила переходов зависят от региона и могут меняться. Долго работающие приложения иногда кешируют timezone при старте, поэтому после исправления системы может потребоваться перезапуск конкретного процесса, контейнера или IDE-терминала. Если локальное время неверно, а UTC совпадает, ищите именно проблему timezone. Если ошибочны и UTC, и локальное время, диагностика уже должна охватывать системные часы Windows и синхронизацию времени, а не только `/etc/wsl.conf`.
Как локализовать проблему, если зона снова неверная
Сделайте три снимка состояния в одной сессии: `date`, `date -u` и текущую настройку Windows. Если UTC совпадает, а локальный вывод отличается на целое часовое смещение, проблема почти наверняка находится в выборе timezone, а не в ходе системных часов. Затем проверьте `/etc/wsl.conf` на явное `useWindowsTimezone=false` и убедитесь, что редактируете конфигурацию именно того дистрибутива, где возникает ошибка. После правки завершите всю виртуальную машину WSL командой `wsl --shutdown`, а не просто закройте вкладку терминала. Если `date` после запуска верен, но приложение продолжает показывать старую зону, перезапустите само приложение и проверьте его переменную `TZ`, контейнер или собственную базу часовых поясов. Такой тест отделяет четыре уровня: Windows, WSL, контейнер и приложение. Не исправляйте региональную зону постоянным числовым сдвигом вроде UTC+2, если требуется корректная сезонная смена времени: для неё важны правила конкретного региона, а не одно фиксированное число.
Что учитывать
Явный `useWindowsTimezone=false` в старом `/etc/wsl.conf` переживает обновления и продолжает отключать наследование зоны. Ещё один вариант — корпоративный скрипт или dotfiles-проект перезаписывает конфигурацию дистрибутива. Если вы работаете на ноутбуке и часто меняете страны, проверьте, обновляется ли зона именно в Windows после подключения к сети; WSL будет ориентироваться на эту сторону. Не путайте название зоны и числовое смещение: переход на летнее время может менять UTC-offset при том же…
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Advanced settings configuration in WSL). Пример и формулировки — редакция N1RO на 2026-09-20.