Proposal regarding tz DB and leap second updates
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
On Mon 2013-08-12T18:44:39 +0200, Martin Burnicki hath writ:
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.
See the efforts of http://calconnect.org/tc-timezone.shtml Be aware that they are working in a framework which does not share all the vocabulary of the IANA tz community efforts and that their draft does not currently transport the information found in the tz "leapseconds" file. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Just as an FYI, in the early, early days of this list there was a proposal (or so I recall) to deliver the tzinfo for, say, America/Los_Angeles as a TXT record in response to a DNS lookup for "Los_Angeles.America.zoneinfo.tz ". As far as I know, nothing ever came of it.
Martin Burnicki wrote:
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.
Have you looked at Internet RFC 4833? It specifies a DHCP option for disseminating TZ settings. It's not exactly what you're asking for, but it should help you get started on how to add that sort of thing to DHCP.
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.
Sure, you could add an option ('-S file', say) to zic.c, with documentation in zic.8.
Since it's useful to leave in placesupport for the current way of specifying leap seconds, a NIST-to-current conversion script may be in order. --ado On Mon, Aug 12, 2013 at 3:20 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Martin Burnicki wrote:
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.
Have you looked at Internet RFC 4833? It specifies a DHCP option for disseminating TZ settings. It's not exactly what you're asking for, but it should help you get started on how to add that sort of thing to DHCP.
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.
Sure, you could add an option ('-S file', say) to zic.c, with documentation in zic.8.
On our own server we run a cron job that looks for new versions of the tz database at iana every 4 hours. This is done using wget & ftp. It then downloads any new versions it finds to our own ftp server. Then, our Windows product, Time Zone Master, installed on client machines, polls our own ftp server for updates every 4 hours (when the app is running) using anon ftp. When a new version is found, it is downloaded to the clients Windows machines and uncompressed in the background, then the app then uses the new tz files immediately. New versions are simply identified by the tzdata filename. No special new protocols. Perhaps you could implement something similiar? On 2013-08-12 12:42, Martin Burnicki wrote:
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
--
participants (6)
-
Arthur David Olson -
Bradley White -
David Patte ₯ -
Martin Burnicki -
Paul Eggert -
Steve Allen