Windows 10 время по utc

Categories:

• Компьютеры
• IT
• Cancel

Эту операцию необходимо провести всем дуалбутчикам к которым с недавнего времени отношусь и я. В противном случае у вас при перезагрузке в Windows будет показываться совершенно непонятное смещение времени.

В реестре необходимо создать или изменить параметр:

[HKEY_LOCAL_MACHINE\SYSTEM\CurentControlSet\Control\TimeZoneInformation]
«RealTimeIsUniversal»=dword:00000001

Ну, а кому сейчас легко

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

Все это происходит из-за различий формата хранения времени в этих операционных системах. И будет происходить при каждой перезагрузке, сколько бы вы ни устанавливали правильное время. Но эту проблему можно решить. И даже несколькими способами. В этой статье мы рассмотрим, как решить проблему сбивается время в Ubuntu и Windows.

Почему так происходит?

Как я уже сказал, проблема в разных форматах хранения и восстановления времени. В компьютере есть два вида часов. Аппаратные — идут всегда, даже когда компьютер выключен и программные часы, встроенные в ядро. Когда компьютер включается значение аппаратных часов записывается в программные, и в дальнейшем операционная система берет время оттуда. Но Windows и Linux работают по-разному с этими двумя часами. Есть два способа работы:

• UTC — и аппаратные, и программные часы идут по Гринвичу. То есть часы дают универсальное время на нулевом часовом поясе. Например, если у вас часовой пояс GMT+3, Киев, то часы будут отставать на три часа. А уже пользователи локально прибавляют к этому времени поправку на часовой пояс, например, плюс +3. Каждый пользователь добавляет нужную ему поправку. Так делается на серверах, чтобы каждый пользователь мог получить правильное для своего часового пояса время.
• localtime — в этом варианте аппаратные часы тоже идут по Гринвичу, но програмные часы идут по времени локального часового пояса. Для пользователя разницы никакой нет, все равно нужно добавлять поправку на свой часовой пояс. Но при загрузке и синхронизации времени Windows вычитает из аппаратного времени 3 часа (или другую поправку на часовой пояс), чтобы программное время было верным.

Так почему же сбивается время Ubuntu и Windows? Вот, допустим, работает Windows, и со временем там все нормально, оно сохранено в формате localtime. Но при перезагрузке в Linux, операционная система берет время Localtime, и думает что это UTC. Таким образом, пользователь будет брать уже правильное время, и прибавлять к нему поправку на часовой пояс. Поэтому время уже будет неверным.

Дальше вы исправили время, и теперь аппаратные часы работают в UTC. Но затем грузите WIndows. Система думает, что это localtime и для установки правильного программного времени добавляет к аппаратному поправку на часовой пояс, например, в нашем случае +3. Дальше каждый пользователь еще раз применяет эту поправку и время уже сбито, опять.

Единственно верный способ решить эту проблему — заставить обе системы работать по одному формату и сделать это совсем несложно. Причем можно пойти двумя путями: либо заставить Windows работать по UTC, либо Linux по формату localtime, что является не совсем правильным, но вполне возможно. Итак перейдем к решению проблемы сбивается время в Ubuntu.

Настройка Windows для работы по UTC

Итак, если у вас сбивается время Windows и Linux при переключении между операционными системами, лучшим способом будет заставить Windows работать по более правильному и логичному формату. Для этого достаточно добавить один ключ реестра. Вы можете сделать это с помощью одной команды в консоли. Чтобы открыть консоль в Windows 10 проведите мышь в левый нижний угол, затем нажмите правую кнопку. В контекстном меню выберите Командная строка (администратор):

Дальше наберите команду для 32 битных систем:

> Reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1

А для 64-битных, нужно использовать тип значения  REG_QWORD:

> Reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_QWORD /d 1

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

> sc config w32time start= disabled

Как вернуть обратно?

Если вы хотите вернуть все как было, то сделать это можно проще простого. Сначала возвращаем ключ реестра в правильное положение:

> Reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 0

И запускаем обратно службу синхронизации:

> sc config w32time start= demand

Готово, а дальше рассмотрим, как заставить Linux использовать формат времени localtime.

Настройка Linux для работы localtime

По умолчанию Linux использует формат хранения времени UTC, но если Ubuntu  сбивает время Windows, вы можете очень просто заставить систему хранить в аппаратном таймере местное время. Во всех дистрибутивах, использующих Systemd, в том числе в Ubuntu для этого достаточно выполнить команду:

sudo timedatectl set-local-rtc 1 --adjust-system-clock

Чтобы посмотреть текущее состояние аппаратных и программных часов выполните:

sudo timedatectl

Готово, теперь вы можете перезапустить компьютер и запустить Windows, чтобы убедиться, что время не сбивается при перезагрузке. В более старых системах Ubuntu, вам нужно отредактировать файл /etc/default/rcS и заменить UTC=yes на UTC=no. Вы можете сделать это командой:

sudo sed -i 's/UTC=yes/UTC=no/' /etc/default/rcS

Как вернуть обратно?

Опять же, вернуть все как было можно с помощью одной команды:

sudo timedatectl set-local-rtc 0

А в старых дистрибутивах Ubuntu:

sudo sed -i 's/UTC=no/UTC=yes/' /etc/default/rcS

Выводы

Вот и все. Теперь, если вы столкнетесь с проблемой Windows 10 — сбивается время Ubuntu или любом другом Linux дистрибутиве, вы уже будете знать, как её решить с помощью двух полностью работающих способов. Если у вас остались вопросы, спрашивайте в комментариях!

Мы разобрались, как настроить правильное время в Ubuntu и Windows, чтобы временные зоны не сбивались, но что такое временные зоны и зачем они нужны, на завершение видео про это:

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Yep, I had success. Don’t forget disabling the «internet update» for the time!

I used the way described in the ArchWiki using a QWORD on a 64bit Win10.
The NTP is done on Arch and not on Windows, but the latter isnt getting booted so often anyway.

Here’s the .reg file:

RealTimeIsUniversal.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
     "RealTimeIsUniversal"=hex(b):01,00,00,00,00,00,00,00

From ArchWiki: UTC in Windows

Using regedit, add a DWORD value with hexadecimal value 1 to the
registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

Alternatively, create a *.reg file (on the desktop) with the following
content and double-click it to import it into registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
 "RealTimeIsUniversal"=dword:00000001

If the above appears to have no affect, and a 64-bit variant of
Windows is being used, using a QWORD value instead of a DWORD value
may resolve the issue.

Если вы работаете с несколькими операционными системами, то настройка всех систем для работы по UTC может быть полезной в избежании проблем с временем.

Это позволит сохранять одинаковое время на всех системах, что упростит работу с файлами, сообщениями и другими данными, которые содержат временные метки.

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

Для чего это нужно?

Настройка Windows для работы по UTC (Coordinated Universal Time) может быть полезна в нескольких случаях:

Работа с множеством операционных систем: Если вы работаете с несколькими операционными системами на одном компьютере, то настройка всех операционных систем для работы по UTC может помочь в избежании проблем со временем.

Работа с серверами: Если вы работаете с серверами в разных часовых поясах, то использование UTC может помочь в синхронизации времени между серверами и избежании проблем с временными метками.

Работа с программами, требующими UTC: Некоторые программы могут требовать работы с UTC, поэтому настройка Windows для работы по UTC может помочь в избежании проблем с этими программами.

Облегчение работы с переходом на летнее/зимнее время: Если вы живете в регионе, где используется переход на летнее/зимнее время, настройка Windows для работы по UTC может облегчить работу с этим переходом и избежать проблем с временем.

Избежание проблем с часами реального времени на компьютере: Некоторые компьютеры могут иметь проблемы с часами реального времени, которые могут вызывать сбои в работе операционной системы и программ. Настройка Windows для работы по UTC может помочь в избежании этих проблем.

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

Как выполнить настройку? Пошаговый порядок действий

Windows по умолчанию использует локальное время для отображения времени в интерфейсе пользователя и в системных файлах. Однако, если вам нужно настроить Windows для работы по UTC (Coordinated Universal Time), вы можете сделать это, выполнив следующие действия:

Откройте редактор реестра, нажав клавиши Win + R и введя команду regedit.

В редакторе реестра перейдите к следующему ключу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation.

Создайте новое значение с типом DWORD и названием RealTimeIsUniversal.

Дважды щелкните созданное значение RealTimeIsUniversal и установите значение 1.

Закройте редактор реестра.

Измените часовой пояс в настройках Windows на UTC.

Перезагрузите компьютер, чтобы изменения вступили в силу.

После этих действий Windows будет использовать UTC вместо локального времени для отображения времени в интерфейсе пользователя и в системных файлах. Обратите внимание, что изменение часового пояса на UTC может повлиять на работу некоторых программ, поэтому рекомендуется проконсультироваться с разработчиками программ, которые вы используете, перед изменением часового пояса.

I recently enabled SNTP on my DHCP server to broadcast my time server’s address (DHCP option 042) and TZ offset(DHCP option 2) to non-Windows/Non-AD devices (Switches, Routers, VOIP Devices, Etc) that don’t know to look for their time server from my AD servers.
I miscalculated the Offset because it rejected the Offset on the switches that got the right UTC time, but I didn’t really care if the switches reported UTC time so I left it alone.

The next morning, a handful of my users reported that their Windows 10 Desktops were showing their time in UTC. I quickly jumped on my DHCP server and removed the DHCP Options from the server to prevent it from pushing it out to additional clients. However
about a dozen of my 200+ desktops appear to have got this change pushed out by DHCP.

I looked in Date & Time Settings and saw that the time was set to UTC. I tried to manually reset the Time zone to our correct time zone «(UTC-04:00) Atlantic Time (Canada)» from the GUI for the effected users but a few hours later the time
zone reset to UTC.

Rebooting does nothing to cure this, in fact doing so seems to reset the Time Zone back to UTC.

I did some research and I found where DHCP stores its Options in the Registry:

\\HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<HASH>\DHCPInterfaceOptions\

However the value is stored in Binary and is unreadable and apparently undocumented. However research indicated that this gets repopulated when you get a DHCP lease. So thinking that this was where the DHCP options were hiding out I deleted the key, cleared
my DHCP lease and requested a new one. the values in this key looked different. And my Time zone seemed to be holding at Atlantic time however the next day, my same pool of users all reported their time had reverted back to UTC.

I tried manually setting the Time Zone in the registry here:

\\HKLM\CurrentControlSet\Control\TimeZoneInformation\

But again by the next day, all my effected users reported the issue again.

I was pretty certain that my Windows time server was working properly because none of my other users/desktops were reporting this issue. It was contained to just this handful of users. However I started to collect some additional diagnostic information from
both desktops that were experiencing the issue and those that were behaving normal.

First I queried DHCP using a tool I found online called DHCPTest on both good and bad clients. This tool outputs every option that your DHCP server is presenting to DHCP clients. This was to confirm that I had successfully removed the DHCP Options from my
server and that they were not still being pushed out somehow. DHCPTest also confirms that DHCP is working properly as part of its testing. Both sets of clients confirmed that DHCP was not pushing the Options out to anyone and that DHCP seems to be working
fine.

Next I used TZUTIL to confirm my Time Zone was correct. I also used it to set the Time Zone on my effected clients. But the time quickly reset to UTC by next day.

Finally I confirmed my Windows Time Server and client machine Time Services were working properly using W32TM. This confirmed that my time Server was configured correctly, that my clients were receiving their time from the Time server and that they were
in fact properly in sync.

I did alot of research found several articles that seemed to point to Windows 10’s Automatic Time Zone behavior as a potential cause. All of these seemed to point to a recent Windows Update as a cause(we didn’t receive any updates on these effected clients
that were not also pushed out to all my clients that are working properly.) or that you have the option «Set Time Zone Automatically» turned on. (We have it off on our clients)

I learned that the Automatic time zone feature may default to UTC if it can not accurately resolve the Time Zone using GPS, Cell Towers, Region or IP Addresses, but since it’s off and manually set, this shouldn’t be our issue. For giggles I did cycle it
on on a couple of our effected clients to see if they might autodetect our proper time zone, but this doesn’t seem to have worked so I turned it back off.

So by this point I felt like I’d verified that it was not a setting in our Registry or a setting from our DHCP or Windows Time Server causing the continual change so I started looking closer at my users.

We use VMWare Horizon managed virtual desktops and VMWare Horizon UEM to manage user profile settings. I confirmed that my Golden Images were all fine and set to the correct Time Zone and Time.and built several new desktops.

In UEM, I purged all of the effect user’s UEM captured user settings. Then I gave my effected users completely new virtual machines and had them log back in. This is effectively like sitting a brand new user with no profile down at a brand new Windows 10
machine. It felt like overkill but I was really at the end of things to try. I configured the users on their new machines, confirmed their Time Zone was correct and then touched the nearest piece of wood for luck.

However the next day the issue came back.

None of my servers(on the same AD network) have been effected and no new users have been effected. It is contained fully to this handful of users.

I’m at a complete loss. I’ve done everything I can think of. My colleagues are out of ideas as well. I know this could easily be any number of things. It might be a VMWare thing, an AD thing, a DHCP thing or a Windows 10 thing. 

Any suggestions would be appreciated.

Crossposted to respective Reddit and VMWare forums as well.