Good to know. For the case I refer to the local time on the device is most important (as local time goes into report), not UTC time. If using this time machine human operator is responsible for setting time zone correctly on their notebook from location data to get local time at location be correct.
IMO it’s never a good idea to use local time to synchronize time across devices.
Imagine your device receives the time once per minute and then checks if its local time is correct.
At the beginning or end of DST, the next time information may be sent immediately before the DST status changes, so the client(s) may get the changed local time up to 1 minute delayed.
Even worse, if the client (like Windows, Linux, …) distinguishes between UTC and local time, this may cause a step in the underlying UTC system time, and another step back shortly thereafter.
Those UTC time steps won’t be visible at the first glance, but may really mess up other applications, e.g. database apps.
This is why time synchronization is usually made based on UTC (e.g. NTP) or TAI (e.g. PTP), and the client does the conversion from UTC to local time according to his preferences.
A good way to distribute local time would be to distribute the time zone rules which the client should use for a local time conversion, so the clients could be updated remotely but avoid the potential problems you get when distributing local time.
The tzdist protocol could be used to do that, but as far as I know it has not yet been implemented for this purpose.
For more details, please see also
https://kb.meinbergglobal.com/kb/time_sync/tzdist
1 Like
@Martin_Burnicki said:
IMO it’s never a good idea to use local time to synchronize time across devices.
This was a purpose built legacy device overloaded by legal regulations.
There was no time synchronization between devices at location. The valid report from a stand alone device was the sole purpose.
The task was simple - when creating a report on a notebook computer every entry must be time stamped. All that was needed is simple “what is correct local time now where I am at” when there is no radio reception. The solution wasn’t simple back then.
This becomes long story away from NTDEV scope, so I wrap up here.
OK, so just for completeness: There are GPS receivers out there which can be configured with some rule to derive local time from GPS/UTC, including automatic switching to/from DST, and the local time can be output via different means.
As you have no doubt discovered by now, there is nothing simple about counting time 
from the simple month/day versus day/month ambiguity to Einstein’s simultaneity thought experiment results - which result in special and later general relativity - time is hard to observe and harder to count!
and lawyers are especially bad at doing it - except in the special case of tallying how much of it that they have spent on your behalf and therefore how much you owe.
there may be nothing that you can do against monuments of stupidity, but the absolute rule is simple - time values that get stored persistently, should be stored in UTC. and then displayed in whatever local time is appropriate.
1 Like