Multicultural TimeDr. Demetrios Matsakis

By Dr. Matsakis

Multicultural Time

I’ve blogged about the science of time^[1] – but the engineering of time can be just as bizarre. For example, the most popular tourist spot in Prague is the clock at the Old Town Hall, where crowds gather on the hour to see the apostles appear in the windows^[2]. The tourists are focused on the saintly procession. Few realize that on the clock face, just below, shows different time scales. The outer ring of the clock shows Italian time, which starts at sunset. This is the most visible time on the clock because this was the most important time to keep for individuals during the middle ages - how many hours to go before it gets dark. The time in Babylonian hours is also shown [3], along with the positions of the Sun and Moon in the zodiac. These astrological positions were important because if they lined up with your birth sign, well, good things could be expected. An approximation of the time as set by our watches was also there[4]. But they didn’t have time zones, also they didn’t understand and did not correct for the "equation of time", due to the Earth’s variable speed in its elliptical orbit.

Have atomic clocks made things any simpler? Not exactly… Because the history of timekeeping is one of innovation by pioneers who often had no idea that the simple expediencies they make would impact generations to come. In time-transfer, we can see that every mode has its peculiarities.

[Figure 1] The clock face, dating from 1490, has a tortured history.^[5]

GPS Time, also termed GPS system time, is famously off from from International Atomic Time (TAI) by 19 seconds, and from Coordinated Universal Time (UTC) by N-19, where N is the number of leap seconds [6]. So time from GPS is NOT GPS Time. Time from GPS is GPS Time plus N-19 seconds plus a small nanosecond-level correction broadcast in the navigation message’s subframe 4[7] to bring the result closer to UTC(USNO). Users usually don’t have to know or care about these things because their GPS receivers automatically do the math. Other GNSS are different [8-10], but any competent programmer who is leap-second aware can hopefully make everything compatible. (Or not, judging by how may leap-second bugs we’ve suffered through.)

Network Time Protocol (NTP) is the go-to method for transferring time over the internet. Brilliantly conceived by David Mills—with a packet structure that provides 233 ps resolution, perhaps his only mistake was to start counting time from January 1, 1900. That means on February 7, 2036 the bits will roll over and make it look like January 1, 1900. If he had chosen 1980, we’d have had an extra 80 years. But not to worry, NTP version 4 can handle this [11].

How about Precise Time Protocol (PTP)? The PTP Timescale is defined by the IEEE to essentially be TAI, because it has no leap seconds and its first epoch is January 1, 1970, which is before the first leap second [12]. The PTP format allows equipment to pass along the number of leap seconds to relate things to UTC, but all equipment does not necessarily do it [13]. But the ambiguities of PTP terminology go far beyond leap seconds. In practice it has many versions, which they call profiles. Consider the standard picture:

[Figure 2] The TimeTransmitter and TimeReceiver exchange PTP packets. [14] Once all the packets are exchanged, the equation on the bottom right is how the TimeReceiver adjusts its clock.

To compute the difference between the Time Server’s time and the network element is simple math, given the measured number of times that the packets were transmitted and received. But PTP doesn’t happen just once. How long should a TimeTransmitter pause between exchanges? How long should an element wait before deciding that the sequence was interrupted and that the previous transmissions should be ignored? Does each element get its time from the one higher up the chain, which in turn gives its time to the next element (peer to peer)? Or does each element get its time straight from the grandmaster at the top of the chain, with due allowance for the extra delay caused by each intermediate element (end to end)? Should IP addresses or domain names be used? Will only certain network domains be allowed? Which TLV (Type, Length, Value) fields should be used, and which not allowed at all? There is also the High Accuracy Profile, better known as White Rabbit, which requires specialized hardware and therefore costs more to implement. Check out the IEEE’s P1588 Working Group’s “non-exhaustive” list and summary. The formal specifications are behind the IEEE’s (expletive deleted) paywall, but suffice it to say that just about every possible combination of options seems to be represented.

While Two-way systems like PTP are inherently more accurate and precise, they don’t have a monopoly on complexity. Consider the IRIG (Over-Range Instruction Group) family of one-way timecodes. The variants have names from IRIG-A through IRIG-H, each with a unique bit rate ranging from 10 kHz to once a minute. IRIG-J is via RS232. The quantization of IRIG bits can be as fine as 10 milliseconds, but the signals can be delivered to microsecond precision, which translates to accuracy once you allow for the signal’s one-way travel time.

To work with practical time, knowledge really is power. If you know what your system is up against, you can find a solution. Masterclock, like most companies, will work with you to be sure you get what you need when you need it. Well … maybe we do it a little more than most companies.

Footnotes

[1] See my blog on relativity: “Good Things Take Time” 

[2] The Prague Astronomical Clock’s moving sculptures of the apostles. This pair is Jude and Phillip.

[3] Babylonian hours are different length in night and day, so there are always 12 hours of darkness and 12 hours of daylight, starting from the time of sunrise.

[4] This time is most like time as we know it.  It is a fixed offset from GMT.  It ignores time zones, and therefore is also a fixed offset from Central European Time.

[5] The earliest recorded mention of the clock is dated 1410, but the calendar dial was added in 1490 by Jan Ruze.  Legend has it that he was blinded so he could not repeat his work for other cities, and so he disabled the clock by jumping to his death into the gears.  This cursed it so no one could repair it.  The curse wore off in 1552, yet it has stopped working many times since then.   In the last days of WWII, Nazi bullets caused a fire which severely damaged the apostle statues and the clock face.  That took three years to repair, and in 2018 a major restoration was made.

 [6] See “Will we have a negative leap second?”

[7] This is the terminology in the GPS Interface Control Document.  The latest one can be found here: https://www.gps.gov/technical/icwg/IS-GPS-200M.pdf.  Anyone who wishes to program a GPS receiver would do best to use only the official version.  I have twice received queries from people who didn’t realize that their only mistake was to follow an alleged copy of it, which had a mistake.

 [8] Galileo follows GPS in terms of N-19, but their nanoseconds offset is to an average of five European labs’ UTC realizations. Notably absent is the UK’s timing lab (whose acronym is NPL), whose participation was a casualty of BREXIT.

 [9] Beidou time’s formula is N-33, and their nanosecond-level offsets are for China’s timing lab, whose time acronym is UTC(NTSC).

 [10] The oddball is GLONASS, whose system time jumps with leap seconds, but is offset by 3 hours from its timing lab, whose time acronym is UTC(SU). This makes it in Moscow’s time zone.

 [11] See www.ntp.org. Leap seconds can also be handled, although many servers never quite get them right. See Steven Sommers, ION-PTTI, "Suitability of Network Time Protocol (NTP) for Time Dissemination”, 2020.

 [12] I like to describe PTP as NTP on steroids, because it is similar to NTP but has so many innovations.  Unfortunately, it is not designed for the vagaries of the internet because to realize PTP’s precision every component in a network must be PTP-aware.   But in any controlled network, even one stretching hundreds of km’s, it does wonderfully. Read more Masterclock material on IEEE P1588.  

[13]   Some switches, termed transparent switches, are not as transparent as they should be.  That’s because they compute the packet’s delay correction in software, using time deeply internal to their unit, as opposed to the hardware layer.

[14] Today, these are still termed Master and Slave. But the relevant IEEE Working Groups are formalizing a new nomenclature. TimeTransmitter and TimeReceiver are the front runners, with BMC (Best Mastser Clock) becoming BTT (BestTimeTransmitter). I’ll blog it when the decisions are finalized.