[tz] Proposal regarding tz DB and leap second updates
Martin Burnicki
martin.burnicki at meinberg.de
Mon Aug 12 16:42:19 UTC 2013
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'm also going to send this to the leapsecond mailing list, even though
some folks may be subscribed on both lists]
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
More information about the tz
mailing list