Since the w32timesvc was introduced in 0.4.13-dev-618-g e4898e6e0b
we had several problems:
The first problem was when leaving ros running for a few days in bootcd, when the timesvc did trigger
a timesync, then the systems clock became offsync by exactly one hour (tested with Berlin timezone).
This could theoretically be improved a little bit but not fixed entirely by:
0.4.15-dev-2273-g c449929fef CORE14658 [NTOS:EX] Use RtlCutoverTimeToSystemTime to determine the current time zone id
I did *not* port back that commit here.
------
But we had other issues as well, for example there was a crash of the timesvc during 2nd-stage-setup-timesyncing
which was invisible to the users eyes (symptom-free) under normal conditions but which could be made reproducible with DPH. CORE-18922
That's due to the service missing data in the registry that early which is only written there at some later point in time.
In master we fixed that crash properly by
0.4.15-dev-2112-g 7320c989fe and its addendum
0.4.15-dev-2355-g af9df93274
but even then the timesvc did not do anything sane yet during 2nd stage setup.
That would require even more changes on top -> changing the order in which stuff is executed.
Therefore I did *not* port back the two commits above, but instead I decided to
switch the services startup-setting to 'manual' as a workaround (which is not what Windows does),
but it is sufficient for now to avoid the 2nd-stage-setup-crash.
If anybody would decide to follow the master footsteps later more closely (by taking the 3 commits instead)
he should be aware that even in todays master-head-state (2024-04-07) the timesvc negatively interferes when
the system is running while a switch to DST or back from DST is happening. We do set the wrong clock then.
Therefore I feel much safer with setting the Service to manual in the older releases, so that the
user explicitly has to OPT-IN if he intends to test this service. Instead of getting disturbed in the default shipment by its misbehavior.
This workaround is abusing the fact that the user has the ability to OPT-IN via servman only after 2nd stage was completed already.
I tested: The service can still be started via servman in bootcd and LiveCD even with this workaround after 3rd-stage-bootup.
-------
Some more thoughts: Manual NTP-update via the timedate.cpl button can be invoked still,
that does work even without the service, and has an effect on the clock.
But it *does not work properly for me in the bootcd* (although we do properly have the 'automatically adjust DST checkmark set' and the correct timezone is set also for me "Berlin"),
I can still make the clock going off-by-one here sometimes. With and without the 3 commits mentioned above.
It *works even worse in LiveCD*, where that auto-DST-checkmark is not set, and where also the time-zone is not yet set correctly to for me to "Berlin",
but instead to GMT-12:00.
Even if I correct the timezone manually and set the checkmark, I can still get an offby-one-hour when manually invoking the DST update in LiveCD.
Still a lot needs to be done in this context. Therefore we shouldn't disturb the user too much with non-working-automatisms yet.
I will not look into these issues again, until I will find the master to have reached an acceptable state in this context.
It most likely makes sense to first make the checkbox and the timezone correct in the LiveCD before addressing the rest.
I did these tests on 2024-04-07, that means we do have DST-enabled in Germany (summertime).
-------
Side-note:
I considered also disabling the auto-NTP-time-sync-feature in datetime.cpl in the older branches, but
decided against it to not harm the tools use on real MS Windows.
3066a9ab09