[LEAPSECS] Proposal regarding tz DB and leap second updates

[Martin Burnicki]

Hi everybody,

here are some thoughts about ways to make timekeeping simpler, 
especially with regards to DST, and leap seconds.


Some time ago there was a discussion on the tz mailing list about 
frequently changing DST dates in Morocco, and that the Moroc government 
determines the beginning and end of DST only a very short period before 
the changes are to come into effect.

A major problem is the short time period admins have available to deploy 
tz data base updates to machines in a mixed environment e.g. consisting 
of several Unix flavors, and Windows systems.

I know Windows systems don't use the tz DB directly, but unlike older 
Windows version which could only provide DST information for the current 
year, current Windows version can at least provide DST settings for 
several years in their registry, and I could imagine some MS engineer 
has written a script which generates those registry settings from the tz 
DB. ;-)

Updates of those registry settings are usually deployed as Windows patches.

AFAIK even for Unix systems the tz DB updates are usually deployed as 
software updates, e.g. updated .rpm or .deb packages for Linux. So 
whenever there's a change in the DST specs for some country, a server 
admin responsible for different types of machines has to wait until all 
manufacturers or distributors of all the OS types and versions he is 
running on his machines have become aware of a tz DB update, and have 
provided software update packages for all their systems, before all 
machines can be updated consistently, each system type using its own 
update procedure.

This may not be a big deal for users in the United States, or in Europe, 
where DST rules are changing only very rarely. If you don't install tz 
database updates then there's a good chance everything keeps working 
fine since no DST rules have changed. However, for people in Morocco, or 
Israel, or some other countries it seems to be quite a challenge to keep 
everything up to date, if there are changes once every year.

We at Meinberg are manufacturing NTP time servers, and there are often 
requests from customers to use NTP to send local time to the clients. Of 
course this is no reliable solution and caused many sorts of other 
problems which are not obvious at the first glance. However, this shows 
the importance for a way to simplify tz DB updates.

My proposal is to use some sort of network protocol to deploy the 
contents of the tz DB, either for a single time zone used on a system, 
or even for all time zones supported by the tz database.

In my opinion this is similar to DNS or DHCP, or even NTP services.

So a machine could simply run a TZ client daemon which periodically 
contacts a TZ server to check if there is an update available, and 
download the updated data if this is the case. A mechanism like the 
serial numbers used for DNS zone transfers could be used to do this.

Of course the tz information must be deployed in a secure way, but this 
is a common requirement for all kind of network services today, using 
crypto mechanisms, etc.

This would also simplify the update of tz data in embedded systems which 
often don't see any software updates anymore after they have been put 
into operation.


Another important thing which could be implemented in the same protocol 
is handling of leap second information.

I don't want to restart the discussion whether leap seconds are useful 
and required, or not, but the following suggestions can help to simplify 
handling of future leap seconds, if they should occur, and they don't 
hurt but help to handle historic leap seconds, if required to evaluate 
archived data, etc.

Actually the NIST provides a leap second file providing current and 
historic leap second information. This file can directly be handled and 
evaluated by the standard NTP daemon.

There are plans to implement this also in the open source PTP daemon, 
since PTP by default uses TAI for the timestamps in the network packets, 
and a leap second file is a good resource to convert between TAI and UTC.

I know the tz DB also includes a leap second file, which is used for the 
"right" timezones. As far as I know this file provides similar 
information as the NIST file but has a slightly different format.

My proposal is to change the TZ code and DB in a first step so that they 
also use the NIST leap second file format. I'm not aware of any 
operating system which uses the "right" timezones by default now, but as 
far as I can see such modification can be done consistently and 
transparently for the users, since both the tz code and the file can be 
updated consistently. So there should be no problems for folks who use 
the "right" timezones.

Many types of hardware refclocks used to set up stratum-1 NTP servers 
don't provide the NTP daemon with leap second warnings, so those NTP 
servers often have to rely on a leap second file which needs to be 
updated if a leap second has been scheduled. Usually there are about 6 
months time to do so. Also future versions of the PTP daemon will have 
this requirement.

So if the same leap second file format was used for all applications 
then the same file could be shared, and for now, it could be updated 
within any tz database update.

If in the future there should be a network protocol which could be used 
to deploy tz updates, then the same protocol could also be used to 
update the leap second file, if required, and life could become much 
easier for many admins. ;-)

Any comments are welcome.

[I've also sent this to the tz mailing list, even though some folks may 
be subscribed to both lists]


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany