Skok systémového času Windows

[jardaplc]

Zdravím,
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět. (Přesné časy skoků bych mohl dohledat z logů).

Nejsem správce fyzického železa, ale mluvil jsem s ním, říkal že nic neměnil a že se na to podívá.

Dávám to sem ze zajímavosti, jestli jste se taky setkali s něčím podobným.

Pro úplnost když jsem přišel na tento problém, zapl jsem w32tm stripchart a tady jsou částečné logy:

Kód: [Vybrat]

w32tm /stripchart /computer:pool.ntp.org /dataonly /period:300 |
>> Tee-Object -FilePath C:\temp\time_drift_2.log -Append
Tracking pool.ntp.org [162.159.200.123:123].
The current time is 05.01.2026 14:25:18.
14:25:18, +00.0129176s
14:30:18, +00.0165300s
14:35:18, +00.0193773s
14:40:18, +00.0223993s
14:45:18, +00.0199100s
14:50:18, +00.0091434s
...
02:55:21, +00.0417110s
03:00:21, +00.0433553s
03:05:21, +00.0433707s
03:10:21, +00.0450076s
03:15:21, +00.0482284s
04:06:34, -2773.7582560s
04:11:34, -2773.7540893s
04:16:34, -2773.7542422s
04:21:35, -2773.7517265s
04:26:35, -2773.7467640s
04:31:35, -2773.7460565s
...
07:26:35, -2773.6656590s
07:31:35, -2773.6626884s
07:36:35, -2773.6611551s
07:41:35, -2773.6579177s
07:00:21, +00.0128807s
07:05:21, +00.0164778s
07:10:21, +00.0196563s
07:15:21, +00.0216492s
07:20:21, +00.0116391s

Status w32tm:

Kód: [Vybrat]

PS C:\Users\xxx> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 2 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0006809s
Root Dispersion: 10.1682249s
ReferenceId: 0xC0A8C814 (source IP:  192.168.200.20)
Last Successful Sync Time: 06.01.2026 10:57:53
Source: xxxx.yyyy.local
Poll Interval: 12 (4096s)
xxxx.yyyy.local je stroj v lokální síti, ale tam běží čas normálně, spustil jsem stripchart i proti němu a výstup byl stejný jako proti pool.ntp.org. A začalo se to dít 29.12, předtím se to nejspíš nedělo. Ale shodou okolností tam běží něco, co generuje periodické logy každých 5 minut někdy od července, takže to můžu projít jestli se skok objevil už někdy dřív.

[Reklama]

[Karmelos]

Wokna ve 3 ráno provádějí nějaké maintenance, update a podobné, podle mě to i syncuje čas a možná ledasco restartuje - podíval bych se jaký je čas v biosu, podle mě na to ta virtuálka může vidět, respektive nějaký bios a jeho čas určitě vidí tak jestli ten není nějak posunutý. A odhadem v těch 7 to syncuje čas s externími servery.

[redustin]

Jestli třeba v té virtuálce neběží čas Win rychleji a v ty tři ráno se to pokaždé nastaví správně.

[jjrsk]

Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.

S cim problem byt muze, je to, ze MS se dodneska tak uplne nenaucil co je to cas systemu (HW) a co je cas ktery ma zobrazovat uzivateli ...

[Filip Jirsák (forum)]

vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět.

Je ten rozdíl plus mínus pár vteřin pořád stejný? 2773 vteřin je tak divné číslo, že jediné reálné vysvětlení, které mne napadá, je že se to synchronizuje ze dvou různých zdrojů, a jeden z nich jde špatně. Nabízí se ty hardwarové hodiny, tj. ve vašem případě čas ve VMware.

Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.

Nikoli, systém si zjistí čas z hradwarových hodin akorát při startu, a pak už si udržuje čas sám, nanejvýš občas synchronizuje hardwarové hodiny se svým časem, aby v hardwarových hodinách po restartu bylo aspoň něco trochu správného. Systém si totiž umí udržovat čas daleko přesněji, než jak to dělají hardwarové hodiny.

Rozhodně to tak dělá Linux, a nedovedu si přestavit, že by to Windows dělaly jinak.

[Reklama]

[jardaplc]

Tak je to ještě podivnější než jsem myslel. Dle zmiňovaných logů (běží tam věc, co periodicky každých 256,14 vteřiny udělá log. Neptejte se proč. Tak jsem projel log od července a vyfiltroval záznamy, kde dva po sobě jdoucí logy mají jiný rozdíl než 256,14 (plus pár vteřin rezerva). Našel jsem dvojí chování: Zhruba od července do půlky prosince to jelo většinu dnů bez problémů, jenom některé dny došlo ke skokům dopředu a zpět (třeba log v 1:43:19, další ve 2:36:24, další v 1:48:41, a pak několik třeba po deseti vteřinách. Jako kdyby čas skočil dopředu, pak se vrátil zpět a pak chvíli běžel pomalu a v řádu hodin se to srovná). Tohle se dělo 6.8., 11.8., 13.8., 14.8., 10.9., 26.9., 15.10., 22.10., 29.10., 12.11., 10.12. Jiné dny to jelo přesně log každých 256,14 vteřiny . (Kromě 26.10., kde vidím skok ve dvě o 3600s při změne času).
Od 12.12. Se chování změnilo. Každý den dojde ke dvěma skokům . V noci dopředu a ráno zpět. Počet vteřin o který to to skáče se každý den zmenšuje zhruba o vteřinu

Kód: [Vybrat]

12.12. 2794s
13.12. 2793s
14.12. 2792s
...
5.1. 2774s
6.1. 2773s
Skok dopředu je ve 3:20 +- 10 minut. Skok zpět bývá od pěti do osmi. (Proto jsme si toho všimli až teď, kdy někdo přišel do práce ještě před tím skokem zpět a všiml si to).
Uvedené výsledky stojí na tom, že onen log se generuje každých 256,14 vteřiny. Nicméně sedí s měřením oproti pool.ntp.org, které dnes změřilo taky skok 2773s.

Fakt mi to přijde jak kdyby se tam praly dva různé zdroje času a pak to dělá psí kusy.

[RDa]

Udelej paralelni cistou instalaci - zda bude mit stejne chovani.
Pokud ano, tak zapni kernel debugging a pripoj se tam debuggerem - uvidis spousty systemovych hlasek.
Apropo - do Event logu jste se dival?

[jjrsk]

Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.

Nikoli, systém si zjistí čas z hradwarových hodin akorát při startu, a pak už si udržuje čas sám, nanejvýš občas synchronizuje hardwarové hodiny se svým časem, aby v hardwarových hodinách po restartu bylo aspoň něco trochu správného. Systém si totiž umí udržovat čas daleko přesněji, než jak to dělají hardwarové hodiny.

Rozhodně to tak dělá Linux, a nedovedu si přestavit, že by to Windows dělaly jinak.

Aby jirsak, jako vzdyky, nemlel uplne zcesty. kazdej sytem ty tupce, dela to, ze cas od casu se snazi ty HW hodiny nastavit na cas toho systemu. Dela to tux, delaj to widle. A dela to pochopitelne vzdy, kdyz dojde na pokus o nejaky NTP a podobne. A presne jak sem psal, ve virtualni vm stroji se to nepovede. Widle o tom mlcej, tux to zaloguje.

Navic ty zjevne vubec netusis, ze existuje cosi jako vmware tools, coz je soubor driveru a systemovych servis, a mimo jine to zajistuje prave synchronizaci hodin. To je tak, kdyz je nekdo blbej jako Jirsak.

[Paulos]

Zdravím,
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět. (Přesné časy skoků bych mohl dohledat z logů).
...

Pokud jste už vyčerpali ostatní možnosti, podíval bych se, zda nemůže jít o tzv. Secure Time Seeding:

https://learn.microsoft.com/cs-cz/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows

Na té stránce je i úprava registrů, kterou se to deaktivuje.

[jardaplc]

Status z dnešní noci (6.1. na 7.1.)
Došlo ke dvěma skokům o 2772 vteřin, z toho jeden byl pod pět minut. Je teda možné, že skoků je víc, jenom jsou tak krátké, že jsem si jich předtím nevšiml.

Kód: [Vybrat]

03:22:43, +00.0630457s
03:23:43, +00.0627538s
04:10:56, -2772.9436147s
03:25:43, +00.0026144s
03:26:43, +00.0025406s

Kód: [Vybrat]

03:50:43, -00.0001596s
03:51:43, -00.0001518s
03:52:43, +00.0063584s
04:39:56, -2772.9333399s
04:40:56, -2772.9331704s
...
05:00:57, -2772.9284102s
05:01:57, -2772.9283991s
04:16:44, +00.0004886s
04:17:44, +00.0002152s
04:18:44, +00.0002774s

Podíval jsem se do event vieweru (to mě předtím nenapadlo, resp. nejsem tak zkušený uživatel aby se mi v hlavě rozsvítilo koukni do event vieweru)

Tady je výcuc z dnešní noci. (od nejstaršího po nejnovější) pro Protokoly aplikací a služeb/Microsoft/Windows/Time-Service/Operational:

Kód: [Vybrat]

07.01.2026 3:24:47
W32time service has set the system time to 2026-01-07T02:24:47.837Z(UTC). Previous system time was 2026-01-07T03:11:00.782Z(UTC). System Tick Count: 2368186156
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 3:24:47
W32time Service received notification to rediscover its time sources and/or resynchronize time. Reason Code:3 System Tick Count: 2368186156
Reason code description:
0 : An explicit time resynchronization request from an administrator
1 : Power state changes on this machine
2 : Changes to the network interface or to the network topology
3 : State changes within W32time that require time synchronization
The actions that follow this notifcation may impact fine-grained time synchronization accuracy.For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 3:24:47
W32time service has set the system time to 2026-01-07T02:24:47.847Z(UTC). Previous system time was 2026-01-07T02:24:47.846Z(UTC). System Tick Count: 2368186156
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 4:16:17
W32time service has set the system time to 2026-01-07T03:16:17.416Z(UTC). Previous system time was 2026-01-07T04:02:30.344Z(UTC). System Tick Count: 2371275718
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 4:16:17
W32time Service received notification to rediscover its time sources and/or resynchronize time. Reason Code:3 System Tick Count: 2371275718
Reason code description:
0 : An explicit time resynchronization request from an administrator
1 : Power state changes on this machine
2 : Changes to the network interface or to the network topology
3 : State changes within W32time that require time synchronization
The actions that follow this notifcation may impact fine-grained time synchronization accuracy.For more information, see https://go.microsoft.com/fwlink/?linkid=845961.

07.01.2026 4:16:17
W32time service has set the system time to 2026-01-07T03:16:17.426Z(UTC). Previous system time was 2026-01-07T03:16:17.426Z(UTC). System Tick Count: 2371275718
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
To vypadá, že v logu jsou jenom skoky zpět.

Udelej paralelni cistou instalaci - zda bude mit stejne chovani.
Pokud ano, tak zapni kernel debugging a pripoj se tam debuggerem - uvidis spousty systemovych hlasek.

To asi nechám až jako poslední možnost, navíc jak jsem říkal nemám fyzické železo ve správě, takže bych to mohl maximálně poradit správci

Pokud jste už vyčerpali ostatní možnosti, podíval bych se, zda nemůže jít o tzv. Secure Time Seeding:
https://learn.microsoft.com/cs-cz/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows
Na té stránce je i úprava registrů, kterou se to deaktivuje.

Podíval jsem se na konfiguraci a tato funkce je zapnuta (předpokládám že to je defaultní stav). Nicméně vzhledem k tomu, že v event viewru logu vidím jenom skoky zpět, tak mám pocit že spíš ta funkce vrací čas zpět, než že by způsobovala problémy. Ale nevím, zkusím to další noc vypnout a uvidím.

 

[jardaplc]

Tak předřečníci měli správné tušení, dělá to VMware tools
Našel jsem správu v Kernel-General (tato konkrétně je z 1.1.)

Kód: [Vybrat]

Systémový čas se změnil z ‎2026‎-‎01‎-‎01T02:18:12.278453600Z.
na ‎2026‎-‎01‎-‎01T03:04:30.211000000Z: 2777932 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Program Files\VMware\VMware Tools\vmtoolsd.exe' (PID 4296).

Čas RTC: ‎2026‎-‎01‎-‎01T04:04:30.211000000Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false
a pak

Kód: [Vybrat]

Systémový čas se změnil z ‎2026‎-‎01‎-‎01T07:39:59.726921600Z.
na ‎2026‎-‎01‎-‎01T06:53:41.937212200Z: -2777789 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Windows\System32\svchost.exe' (PID 1476).

Čas RTC: ‎2026‎-‎01‎-‎01T07:53:41.937212200Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false
To samé v různé noční a ranní časy každý den o hodnotu, která se pravidelně snižuje.
třeba
1.1. 2777789 ms
2.1. 2777102 ms
3.1. 2776275 ms
4.1  2775442 ms
...

Teď už zbývá jenom zjistit proč to dělá.

S nadsázkou bych mohl říct, že dobrá správa je, při nějakém průměrném snížení skoku 0,8 vteřiny za den do deseti let problém zmizí sám. Špatná správa je, že možná to pak bude skákat dozadu a ntp to bude srovnávat dopředu.

[Marvin]

"Synchronize guest time with host" je zapnuto nebo vypnuto?

[MarekKnapek]

Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/

[František Ryšánek]

Nedočetl jsem se důležitou informaci: máte důvod se domnívat, že ten VMware (hypervizor) má správný čas?
Díval jste se? Bere si ho odněkud přes NTP?

Dál bych zkoumal, zda nemám náhodou povolené dva (či více) mechanismy, aby mi konfigurovaly čas v guest-side OS.
Servisky dolaďující čas toto obvykle činí dolaďováním rychlosti běhu (="frekvence") softwarové časové základny. Pokud se začnou dvě různé zpětnovazební smyčky "pravidelně přetahovat o kormidlo", můžou být výsledky zajímavé.
Nebo jedna smyčka dolaďuje frekvenci, a druhý kousek softwaru dolaďuje periodicky skokem na chybný čas...
Doladění skokem je z hlediska best practices v oboru časomíry nešťastné řešení, ale při velkém rozdílu asi jediné správné.

Tzn. zatím by se hypoteticky mohlo jednat o soupeření mezi nativní MS serviskou w32time (která může brát buď NTP, nebo páchá zmíněný "Secure Time Seeding" ze SSL), vs. VMware Tools.
Kromě toho si guest OS při startu bere čas z emulovaného RTC, jak už tu správně psal Filip Jirsák.
Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.
Dále, pokud by se stalo, že daný VM guest je v nějakých časových periodách držen hodně zkrátka co do přístupu ke strojovému času hostitelova CPU, takže mu softwarová časová základna běží pomaleji, než si třeba v lepších časech nakalibroval, velmi teoreticky by to taky mohlo vést k následným skokovým korekcím...

Neznám VMware. Třeba KVM+QEMU umí guestovi exportovat emulované fyzické hodiny "PHC", pro které je tuším guest-side virtio ovladač. Následně linuxový guest umí toto "autoritativní PHC" využít k doladění své softwarové časové základny, asi by podle toho uměl běžet i ntpd v guestově OS apod. Windows jsou v této oblasti za linuxovým světem vývojově pozadu, ale postupně to zaostávání dotahují. Nedávno přibyla podpora PTP (konkrétní profile), tuším i zárodek podpory pro HW timestamping v síťových kartách, nevím jak obecnější podpora PHC.

[František Ryšánek]

Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/

1.) proti gustu žádný dišputát. Pokud Vám to funguje, klidně si poslužte...

2.) nemá specifickou podporu pro virtuální časoměrná zařízení hypervizoru QEMU+KVM (ani pro VMware)

3.) pokud to použijete, vypněte všechny ostatní způsoby dolaďování času ve VM guestovi = zastavte standardní MS servisku w32time, VMware tools, cokoli dalšího případně sahá na systémový čas

4.) ta věc je zcela banální SNTP klient, původně vyvinutý pro Win98. Tzn. patrně umí reálně méně, než standardní NTčkový w32time, a velmi pravděpodobně méně, než třeba Win32 build ntpd (nějaký binární build mají k dispozici Meinbergové, ale viděl jsem alternativní build i od někoho dalšího).
Ale ten Váš timesynctool bude také citelně méně složitý na konfiguraci, než zmíněné "seriózní" servisky.