Table of Contents

TZDIST

tzdist is a new network protocol to distribute time zone descriptions including a leap second table and thus TAI-UTC offset information via the network.

The protocol has originally been designed to support WebDAV/CalDAV applications, but could also be very useful for standard time synchronization applications.

The Problem

Currently, time zone updates for computers are distributed as software updates only. Whenever a new TZ DB version is rolled out, OS vendors have to generate a software update package for their OS or distro which mainly contains just some updated time zone descriptions.

Accurate current time zone rules are not only required to display correct local time, but also to schedule calendar events for the right point in time.

If an OS version or distro goes out of support then update packages aren't provided anymore, and time zone rules aren't updates anymore, either. For embedded systems this is even worse since often there aren't any firmware updates provided anyway.

:!: As reported in some mailing lists, newer versions of Apple's IOS and Google's Android provide some way to update the time zone data, but usually the phones have to be rebooted to let time zone rule changes take effect.

A Possible Solution

A tzdist client could be a nice extension:

Some RFCs have been published to specify the protocol and server, and there have been implementations for testing.

Actually it's not clear if the test server is still operational. See the discussions

How to Integrate 'tzdist' Data?

Even if a tzdist server is available, and there's a client that fetches the tzdist data from the server, the remaining question is how to integrate the data a client receives from a server.

There's still much room for improvements for this.

Updating a Local Instance of TZ DB

Updating Information for 'ntpd'

A current version of ntpd detects at runtime when the leap second file specified in its configuration file has been updated, and re-reads the file, so the leap second and TAI information can be updated on the fly.

So a tzdist client would have to be able to (re-)write a leap second file if required, or some other mechanism needed to be invented to pass the updated data to ntpd.

'tzdist' Servers


DHCP Option for 'tzdist' Server Addresses

A discussion on this topic was started on the tzdist mailing list, but didn't yield a real result:

Also a ticked was opened, but then closed without any effect:

References


Martin Burnicki martin.burnicki@meinberg.de, last updated 2020-09-08