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