Ed Davies
Computing Papers

2002-04-24

Contents

• Introduction - Time
  • Timescales
  • Leap Seconds
  • Leap Second Problems
  • Future Leap Seconds
• Introduction - Domain Name System
  • Basics
  • IP Addresses
  • "Abuse"
• Proposal
  • Basic Design
  • Server Setup
• Conclusion

Introduction - Time

Timescales

For the purposes of this discussion there are three time scales which are relevant:

TAI

Temps Atomique International (International Atomic Time) is one of the two basic forms of timekeeping. It is produced by the Bureau International des Poids et Mesures (BIPM) as the result of combining the outputs of a number of atomic clocks and it ticks off SI seconds with monotonous regularity. Every TAI day is 86 400 SI seconds in length. (86 400 = 24 × 60 × 60)

UT1

Univeral Time One, is a timescale based on the rotation of the Earth. It is defined by a formula based on siderial time (the rotation of the Earth relative to the "fixed" stars) such that it reflects the average motion of the sun as it appears from the surface of the Earth. Every UT1 day is 86 400 seconds in length but because of the very slightly irregular rotation of the Earth and the long term slowing down of the Earth's rotation these seconds are irregular and not exactly the same as an SI second. In effect, UT1 is a measure of the angle of rotation of the Earth carried out by the International Earth Rotation Service (IERS). As such, it is the other basic form of timekeeping.

UTC

Coordinated Universal Time is a compromise between the previous two time scales. It works in SI seconds and is always an integer number of seconds offset from TAI but leap seconds are inserted or removed (at intervals of about 18 months) to keep it within 0.9 seconds of UT1. A UTC day is therefore usually 86 400 SI seconds but can be 86 399 or 86 401 SI seconds in length.

In casual conversation the term GMT (Greenwich Mean Time) is still often used, typically to mean UTC. However, GMT is not very well defined but it is actually closer to UT1. In some jurisdictions GMT is still the legal form of timekeeping but in practice all time signals and so on are based on UTC. The difference is small enough not to matter for practical purposes. Local time zones, with or without daylight saving time, are therefore in practice defined in terms of UTC usually by an offset which is an integral number of hours but sometimes extra half or quarter hours are involved. We are not interested in local time here.

There are specialist timescales which are used when precisions much better than about 1µs are needed over long periods or great distances. These timescales are required due to relativistic effects but they are not considered here.

Certain applications define their own timescales. For example, the GPS system does this, using a system which was once synchronised to UTC but which does not include leap seconds and therefore has a fixed integer number of seconds offset from TAI (give or take a wobble at the sub-microsecond level).

Leap Seconds

The decision whether or not to apply a leap second is the responsibility of the International Earth Rotation Service (IERS) and is announced in their Bulletin C which is published every six months announcing the presence or absence of leap seconds over the following six months. They also publish what is, in effect, a history of the application of leap seconds in the form of a table showing the relationship between TAI and UTC since 1961.

Leap Second Problems

For most people and most applications leap seconds are no more than a technical curiousity as clocks are typically set to precisions of worse than one second anyway. For a very few applications, those involving timing to accuracies better than about 1µs over long periods and/or great distances, leap seconds are such a large, obvious and trivial problem compared with other considerations as not to be a worry.

Where concern might arise is with systems in between these two extremes. For example, many modern navigation and telecommunication systems rely on synchronisation to better than one second and might not properly handle leap seconds being inserted or removed.

For these systems use of TAI would be the most obvious solution. However, even if this is done user interfaces still need to operate in UTC (or local time) otherwise confusion will result. Markus Kuhn has produced an API proposal which allows handling of UTC, TAI and other timescales in a systematic manner.

The difficulty is that it is not easy for the typical application program or even its operating system to find out reliable information on the relationship between UTC and TAI. We certainly don't want all operating systems to require their users to input the current UTC-TAI value, or worse, the complete history of such values, just in case some application program on the system happens to rely on that information.

Future Leap Seconds

There are proposals that the UTC time scale should not have any further leap seconds from some date in the relatively near future. This would have the effect of freezing the offset between UTC and TAI.

Steve Allen has a page on the subject. His bibliography page is particularly interesting.

This paper takes no position on these proposals other than to point out that having easily available information on the relationship between UTC and TAI slightly weakens the case for removing leap seconds.

Introduction - Domain Name System

Basics

The primary function of the Internet DNS is to convert domain names (such as "www.iers.org") to internet addresses (IP addresses, such as 141.74.254.122). It also has some secondary functions such as providing the inverse of this function (i.e., mapping addresses to names) and providing information used to route e-mail messages.

For this discussion the DNS has some important characteristics:

• Administration is distributed. Owners of many individual domains within its namespace have both the responsibility and freedom to manage the master database for their domain.

• Access is cached. When a client asks for a domain name to be mapped the response is often returned by a local server, without needing to communicate with the master server. Of course, the first time a local server is asked for a particular mapping it must make the request of another server, either one which is authoritative for that domain or at least one closer to the master.

  This caching can be controlled by the master server which can set the time-to-live (TTL) field on a record to a 32-bit unsigned integer number of seconds. The record should not be cached beyond this period.

Access is normally provided to the DNS by operating system calls. Both Unix and Microsoft Windows provide functions to convert domain names to IP addresses. Typically these functions are used by networking software such as web browsers but any other programs which want to can also join in.

IP Addresses

In version 4 of the Internet Protocol, the one which is in most common use today, IP addreses are 32 bit binary numbers. Typically they are written by dividing them into four 8-bit values (bytes or octets) and writing these in decimal, highest order octet first, separated by periods.

For example, the 32-bit address 4278194210 (hexadecimal value FF001022) would be written as 255.0.16.34.

The high order few bits of an IP address tell how the remainder of the bits are to be interpretted with respect to identification of the network to which the addressed entity is connected. In particular, addresses with the first octet set to 127 are reserved for "loopback" - that is, they address the current machine without going out on to the network at all.

"Abuse"

Certain applications use the DNS in ways it was not originally designed to be used. Because of the flexible nature of the DNS these uses can happily co-exist with the more normal applications.

For example, the Open Relay DataBase contains information on e-mail servers which are "open relays" which are likely to be used by spammers. If a program wanted to find out if the IP address 192.89.123.5 was such an open relay it would check for the existence of a certain kind of DNS record for: 5.123.89.192.relays.ordb.org.

The ORDB returns records for these pseudo addresses which indicate IP addresses starting with 127. Presumably, the idea is that if the addresses are accidentally used for real routing then they will be treated as loop-backs and will not waste network resources sending packets going nowhere special.

Proposal

Basic Design

This paper proposes that the offsets of UTC from TAI for each month since the UTC timescale took its modern form (i.e., from 1972-01-01) should be made available by encoding them as pseudo-internet addresses in well-known locations in the DNS.

As the IERS is responsible for the definition of this offset it would seem logical that the data be placed in its domain. This is assumed for the examples given below but any organisation which wished to could host this information. The information is placed in the subdomain "tai-utc".

Each year is given a domain and each month within that year is similarly named. Following the usual domain naming convention of least significant name first 2003 April would be referenced as:

04.2003.tai-utc.iers.org

The appropriate record returned contains data in the form of an IP version 4 internet address:

127.f.n1.n2

The high order octet is 127 to indicate a loop-back address, used so that little harm is likely to arise if the address is accidentally used for routing.

The second to high order octet (f) contains a code indicating the status of the TAI-UTC offset for the month and the format of the associated data. The following values are assigned meanings:

Other values may be defined in the future (with appropriate notice). Software which encounters a value which is not understood must treat it as an error condition and should report to the user that updated software is required. Possible reasons for defining new codes could be that the offset has become negative (very unlikely), the offset has become greater than 2¹⁶ or UTC has been redefined such that the offset is no-longer an integer. Similarly, if an IP version 6 address is returned then this must be treated as an error.

Records are placed in the database for months at least one year beyond the date to which the offset is currently defined. This allows software to look ahead for the next leap second without relying on "negative caching" in DNS servers or causing a lookup to propogate to the master server. As the date when the next announcment will be made approaches the time-to-live of these records can be reduced to ensure that the annoncement is disseminated in a timely manner.

Server Setup

This author has no practical experience of administering DNS servers but believes that the zone file should look something like:

        $ORIGIN    tai-utc.iers.org.
01.1972 IN A 127.0.0.10
02.1972 IN A 127.0.0.10
03.1972 IN A 127.0.0.10
04.1972 IN A 127.0.0.10
05.1972 IN A 127.0.0.10
06.1972 IN A 127.0.0.10
07.1972 IN A 127.0.0.11
08.1972 IN A 127.0.0.11
09.1972 IN A 127.0.0.11
10.1972 IN A 127.0.0.11
11.1972 IN A 127.0.0.11
12.1972 IN A 127.0.0.11
01.1973 IN A 127.0.0.12
02.1973 IN A 127.0.0.12
03.1973 IN A 127.0.0.12
04.1973 IN A 127.0.0.12
05.1973 IN A 127.0.0.12
06.1973 IN A 127.0.0.12
07.1973 IN A 127.0.0.12
08.1973 IN A 127.0.0.12
09.1973 IN A 127.0.0.12
10.1973 IN A 127.0.0.12
11.1973 IN A 127.0.0.12
12.1973 IN A 127.0.0.12

...and so on, tediously, until...

01.2003 IN A 127.0.0.32
02.2003 IN A 127.0.0.32
03.2003 IN A 127.0.0.32
04.2003 IN A 127.0.0.32
05.2003 IN A 127.0.0.32
06.2003 IN A 127.0.0.32
07.2003 IN A 127.0.0.32
08.2003 IN A 127.0.0.32
09.2003 IN A 127.0.0.32
10.2003 IN A 127.0.0.32
11.2003 IN A 127.0.0.32
12.2003 IN A 127.0.0.32
01.2004 IN A 127.1.255.255
02.2004 IN A 127.1.255.255
03.2004 IN A 127.1.255.255
04.2004 IN A 127.1.255.255
05.2004 IN A 127.1.255.255
06.2004 IN A 127.1.255.255
07.2004 IN A 127.1.255.255
08.2004 IN A 127.1.255.255
09.2004 IN A 127.1.255.255
10.2004 IN A 127.1.255.255
11.2004 IN A 127.1.255.255
12.2004 IN A 127.1.255.255

For 2004, the TAI-UTC offset is not, at the time of writing, defined which is indicated by setting the second octet of each pseudo address to 1. The low order bytes are set to a large value (indicating an offset of more than 18 hours) so that if they are accidentally used a gross error which is likely to be detected will arise.

Conclusion

A mechanism has been proposed which allows Internet connected computer systems to determine the relationship between UTC and TAI accurately and with little network overhead. This information can safely be stored and used on the computer when it is not connected to the network as its period of validity is clearly indicated.

Implementation of this mechanism would reduce the pressure to remove leap seconds from UTC and reduce the need to "fudge" time scales in computer systems.