ng similar like RS-232, transmitting ASCII, binary coded decimal (BCD) strings, or timestamp information over short-distance cabling. But the main problem with delivering ToD is agreeing upon the format and content of the messages carry- ing the date and time information. Transferring the time of day between machines is a long-running need, and SO there are many historical versions of this signal, including IRIG and those from the National Marine Electronics Association (NMEA). There are also agreed-upon formats available for the ToD message depending on the industry. Many companies and organizations have their own format, for reasons going back many decades. For ex- ample, NMEA sentences are used to transfer time (plus position and a lot of other information) between navigation systems (such as Long-Range Navigation [LORAN] or GPS receivers) and other equipment on the bridge of a ship. For telecommunications and packet-switched networks, one frequently encounters UBX (defined by the uBlox company), various NMEA sentences, NTP driver format, and even a Cisco-developed format. Obviously, there are considerable interoperability issues with having SO many electrical and phys- ical versions of this signal, without even considering message format. For this reason, the ITU-T has developed a recommendation to base ToD on a V.11 signal with defined message formats. The details of this format for ToD, as well as the 1PPS signal, are outlined in Annex A of G.8271. The ITU-T specifies that the ToD signal should not start before the 1PPS it represents, should take no longer than 0.5 seconds to transmit, and be sent once per second. They define three message types, but only one, the Time Event Message, is used to transfer time. The time is sent as a PTP/TAI timestamp which is a 48-bit unsigned integer representing the number of seconds since the PTP epoch (1 January 1970). The message also contains enough additional information (for example, leap second offset) to be able to reconstruct UTC. The ToD signal is not used in TDM 