_:nab74802953dd442aba032c097d809e9fxb48
<http://schema.org/text>
"In my opinion, I'd try fix the OS configuration, or use a 3rd party if the default provided by the OS isn't good enough.\n\n\n\n\t \n\n\n\n\tFrom an application perspective, there should be a level of trust on basic services provided by system, otherwise there would be a lot of app bloat if everyone had to distrust them... When it comes to the APIs we use from the OS or the RTL, the key thing we need to pay attention to is the locale configuration (defined by the OS again), and use the appropriate toUTC/fromUTC type functionality. This is especially important when applying these functions appropriately when obtaining data from 3rd party sources and converting the timestamps appropriately, which would normally be sourced in UTC.\n\n\n\n\t \n\n\n\n\tOn windows (desktop and server), there is w32tm.exe (windows time service) https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings. On my workstation this was disabled till I enabled it, but the other benefit is that within a larger organisation, the sysadmins could script something to deploy and enable appropriately with whatever the standard is so that everyone was covered consistently.\n\n\n\n\t \n\n\n\n\tI have worked on time sensitive apps before where we had 3rd party time agents on the host machine that synchronised the time, and custom libraries that worked with those agents, but this was because there was a very very low tolerance for any time drift at any time because the application was financial in nature working on financial market data in realtime and logging  required more granular timestamp information.\n\n\n\n\t \n\n\n\n\tI'd try to stick to RTL functions or standard system calls like what @Wagner Landgraf referenced above, but that is my opinion.\n\n\n\n\t \n\n"
<https://en.delphipraxis.net/topic/5352-how-to-get-the-actual-utc-time/?tab=comments#comment-46221>