@toiletobserver
i see two things, boot entries and the hardware clock.
AFAIK with uefi windows wants to be the first entry in uefi boot list, otherwise it will set it and overwrite the boot mechanisms but one can set the entry to be first but disabled, thus uefi boots the next active entry every time while windows doesnt overwrite the boot settings during updates. i tested this to some degree, but i do not boot windows on that machine often enough, so i dont know what really happens on updates. i got this info from the evil internet and it sort of made sense while not harming at all so i did it that way and it used grub all the time up to now.
take care to have a backup of boot entries to quickly restore them in case microsoft overwrites things without beeing asked to.
second things is rtc clock.
in the past windows stored local time in the hardware clock while linux usually set the more sane utc value. if these settings concurrent, there will be surprises and time jumps depending on what bootet last and updated the hw clock.
i guess microsoft will rather stick to the option that is less sane and causes overall more problems, so i guess you should have a look at it, and if there are problems, either set windows to put/expect utc or linux to put/expect local timezone to/from hw clock.
i might be wrong and they already solved the problem when designing uefi definitions, but better look at it or at least observe it somehow.
my 2 cents





@toiletobserver
the effect of utc vs local time would always jump by your timezone offset to utc which is usually whole hours and some timezones have half or quarter hours or such, IMHO it shouldnt cause clock “drift”, that is unless thats a feature of windows time handling when the time has a huge offset.
ntpd used to slightly adjust the clock only if the offset to remote servers is something like few seconds and would “step” to immediately correct the system clock if its larger.