Score:0

Windows Server 2012 R2 with hour/time issues

jp flag

In my office, we have a Windows Server 2012 R2 with our SQL Server on it. We are located in a UTC-7 timezone where we "suffered" DST (but not anymore).

Multiple times a day, our server clock adds 7 hours to itself to coincide with the hour on UTC+0, but the timezone on the server is still set to UTC-7.

We tried changing the time zone to Arizona (UTC-7), where they never used DST, unchecked time sync on any server, and multiple combinations with no success.

There is a similar post on Windows Server 2012 R2 time resetting by 2 hours (-2 hours) .

EDIT: When running the "Verbose command" it displays this (it's in spanish)

Indicador de salto: 0(ninguna advertencia) Capa: 2 (referencia secundaria - sincronizada mediante (S)NTP) Precisión: -6 (15.625ms por tick) Demora de raíz: 0.0471270s Dispersión de raíz: 7.7761138s Id. de referencia: 0x84A36001 (IP de origen: 132.163.96.1) Última sincronización de hora correcta: 05/05/2023 3:09:29 PM Origen: time.nist.gov,0x9 Intervalo de sondeo: 10 (1024s)

Desplazamiento de fase: 0.0245049s Frecuencia de reloj: 0.0156250s Equipo de estado: 1 (En espera) Marcas de origen de hora: 0 (Ninguno) Rol del servidor: 0 (Ninguno) Último error de sincronización: 2 (El equipo no se sincronizó porque solo tenía información obsoleta de hora.) Tiempo desde la última sincronización de hora correcta: 9246.2271045s

EDIT2: When running a log file for w32t, it showed this change when I, on purpose, changed the time on the server two hour to the futured and changed it back:

154256 22:42:52.4270465s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE
154256 22:43:02.5275511s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE
154257 00:43:10.8521663s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE
154257 00:43:20.9464343s - W32TimeHandler called: 
SERVICE_CONTROL_INTERROGATE

154257 00:43:31.0634751s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE

154257 00:43:35.9394523s - W32TmServiceMain: timeout

154257 00:43:35.9394523s - Sample Prepared at 133278074159394523 for peer time.nist.gov,0x9 (ntp.m|0x9|0.0.0.0:123->132.163.96.1:123)

154257 00:43:35.9394523s - NtpClient returned 1 samples.

154257 00:43:35.9394523s - Sample 0 offset:+00.0245049s delay:+00.0471270s dispersion:07.8731303s

154257 00:43:35.9394523s - Intersection successful with 0 dropped samples.

154257 00:43:35.9394523s -   0: Sample:0 SyncDist:238966938 SelectDisp:0

154257 00:43:35.9394523s - Sample 0 chosen. Select Dispersion:00.0000000s STC:7022766

154257 00:43:35.9394523s - ClockDispln Update: *STALE*(NextSTC=7022766 <= LastUTC=7022766) Hold(1)

154257 00:43:35.9394523s - W32TmServiceMain: waiting 1024.000s

154256 22:43:38.7084419s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE

154256 22:43:48.8421763s - W32TimeHandler called: SERVICE_CONTROL_INTERROGATE
Jake C avatar
jp flag
I forgot to add, we already checked the BIOS clock and it's also set to UTC-7 with no DST.
cn flag
Time synchronization isn't related to DST or time zones. It only uses UTC. There is verbose logging for the time service. That needs to be enabled and would be a minimum to pursue this to determine the source. https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/turn-on-debug-logging-in-windows-time-service If this server is part of a domain, it must synchronize time with Active Directory, no exceptions. There needs to be output of the configuration from `w32tm /query /status /verbose`. If it is a virtual, the virtualization platform time synchronization must be disabled.
Jake C avatar
jp flag
There's no domain controller or Active Directory, it's not a virtual server or any kind of virtualization environment. What really bothers me is that the change is always 7 hours to the future and that we are in a UTC-7 timezone. Also, all of this happens exactly the same wether the timesync is on or not. I'll try that verbose thing and let you know.
Jake C avatar
jp flag
There's another server that runs some tools Apps, ERP, etc. It also runs Windows Server 2012 R2 on Arizona's UTC-7 and the time on it doesn't change.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.