kb:time_sync:basics:why_not_synchronize_local_time

Why Not Synchronize Local Time?

It's never a good idea to use local time to synchronize time across devices that distinguish between UTC and local time zones.

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 of 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 the preferences of the user.

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 the KB page on tzdist.


Martin Burnicki martin.burnicki@meinberg.de, last updated 2021-07-20

  • kb/time_sync/basics/why_not_synchronize_local_time.txt
  • Last modified: 2021-07-20 10:43
  • by 127.0.0.1