Similar to the cleaning lady analogy, I don't handle windows.
My expertise lies in various ntp daemons on unix-like machines accumulated over the years.
ntpd is designed not for making drastic time adjustments but rather for fine-tuning the system clock's speed. If a significant step is needed, it indicates that your machine's initial time was way off or there's a clock issue (or possibly poor hardware).
In normal circumstances, ntpd ensures a continuous and smooth timescale without major disruptions (although there may be slight variations). Only when the gap between system time and UTC is excessively large does a "step" occur, potentially causing time to reverse, with notifications typically being logged if this happens.
System time steps can lead to other complications as well, such as confusing make commands.
Modern ntpd provides options to adjust the threshold at which a step is triggered.
Possible solutions:
You could monitor where your systems log NTP step occurrences and respond accordingly (though this may be challenging across different platforms).
Rather than relying solely on system time, consider using an alternate time measurement method.
If accessing a public NTP server directly isn't feasible, retrieve time information from a server with a reliable clock via http(s) instead. While not as precise as NTP, if you're dealing with differences of around 30 seconds, the impact of using http(s) might be minimal.
If high accuracy is crucial, tunnel NTP through http(s) to a webserver and let NTP manage the transmission delay. It involves additional effort, but could be a solution in urgent cases.
For environments within a corporate setting, setting up internal NTP servers is relatively straightforward. Alternatively, ready-made timeservers are available for purchase (e.g., Meinberg) and network time can be broadcasted using NTP within the local network.
However, I do have reservations about the necessity of accurately measuring time elapsed within an application.
Further details can be found here: