Fullscreen HTML5Med Res (??MB)HTML4

Feature by Tim Blythman The Y2K38 Bug and other time gremlins After much promised chaos, the Y2K bug turned out to be a fizzle, partially due to diligent actions taken by many to correct it before it happened. But other less obvious date- and time-related bugs are coming up, especially in 2036 and 2038. S etting aside the year 5851444 bug mentioned in the WiFi Time Source article – I think we probably have time to deal with that one – there are three well-known bugs potentially affecting time-handling protocols that are expected to occur much sooner, in the 2030s. While that might sound like a while away, it is now nearly 15 years since we first published a GPS clock project. There is a good chance that the WiFi Time Source will be obsolete in 15 years, although some will no doubt still be in use. So we had to ensure it would not be affected by any of these potential pitfalls. The following discussion might seem excessively cautious, but many people will recall some of the strange things that happened (or were predicted as happening) around the time of the “Millennium Bug” (Y2K). All these bugs are tied to dates in the future, but like the Millennium Bug, symptoms have already occurred before their relevant dates, primarily due to references to future dates. It’s probably due to these previous occurrences of these bugs that we are now suitably prepared to handle their arrival. 2036 The original NTP protocol uses a 32-bit timestamp (number representing a time) for the number of seconds since the 1st of January, 1900. Another 32-bit number is used to represent fractions of a second, giving a resolution of 232 picoseconds. This means that the counter used for NTP timestamps will roll over on the 7th of February, 2036. Fortunately, the NTP designers considered this possibility and the rollover, on its own, will not be a problem. While NTP transmits absolute timestamps, the main use of NTP is to set and maintain clocks that are capable of keeping time themselves. Checks are performed to validate clock sources 70 Silicon Chip and even prioritise which should be used in case many are available. The NTP protocol is designed to reckon its updates based on the current time (and date). In the worst case, the ‘true’ NTP time must be within 34 years of the system’s current time to perform these calculations correctly. 34 years is one-quarter of the 136year span that the 32-bit timestamp can represent. This allows enough spare bits to perform the correct binary arithmetic. As early as 2004, it was reported that some systems with default dates of 1970 (which is common as the beginning of the UTC epoch, see below) were unable to correctly update their time since the necessary adjustment was more than 34 years. The WiFi Time Source project uses a default date in 2022, and thus should have no trouble with NTP until at least 2056. We’ve made the default year adjustable, and even when it was set more than 34 years away from the present, it was able to synchronise correctly. So we expect that as long as this is updated every decade or so, there should be no problems with its NTP implementation. Interestingly, the timestamp represented by all 64 bits being zero (including the fractional part) is considered invalid. This timestamp will occur for 232 picoseconds on the 7th of February, 2036. The worst that might happen in this case is that the timestamp is discarded as invalid and an update is missed. The internal clock will continue to keep time and should be updated later. 2038 bug one (Unix time bug) The subsequent expected bug will manifest on the 19th of January, 2038, at 3:14:07 UTC (Coordinated Universal Time). UTC is roughly the modern equivalent of GMT (Greenwich Mean Time), based on solar time at the 0° (prime) meridian of longitude. Australia's electronics magazine Unix time measures the number of seconds since the start of the 1st of January, 1970. Like NTP, Unix time is often encoded as a 32-bit timestamp. Unlike NTP, this number is often interpreted as being signed, allowing dates back to the 13th of December 1901 to be represented. As you might guess, the signed 32-bit counter rolls over in 2038, and some systems will interpret these dates as being out by around 136 years. This bug is most like the Millennium Bug in its cause and possible effects. However, many computer systems are now switching to 64-bit processors (or have already switched), and using a 64-bit counter will prevent bugs on such systems. It will most likely be older, unmaintained computers and embedded systems that will be affected by this, as they will be less likely (or unable) to receive updates to correct this problem. Thankfully, the Pico W’s C SDK uses a 64-bit counter to keep track of time, even though it is only a 32-bit device. This has a resolution of microseconds and is what we use to primarily keep track of time in the WiFi Time Source. So as far as that design is concerned, this bug is not an issue. The NTP library actually passes a 32-bit Unix timestamp to set the time, as an unsigned value. This is reasonable as negative values map to times before 1970 and are thus not expected to occur. Thus, the Unix time bug is not expected to affect the WiFi Time Source until the 32-bit counter hits its unsigned limit in February 2106. We’ve set a reminder in our calendar to deal with it in mid-2099; that should be enough time to sort it out. 2038 bug two (GPS rollover) A time bug related to GPS is also expected to occur in 2038. This will not affect the WiFi Time Source as it’s related to technology used in the GPS satellites, and we don’t take any siliconchip.com.au ► 0.8 0.6 Left: a plot of UTC vs mean solar time (UT1); the vertical sections show leap seconds while the slope of the graph shows the relative drift speed and how it has changed over time. Source: https://w.wiki/6S8w 0.4 0.2 0 -0.2 -0.4 -0.6 -0.8 1976 1982 1988 1994 2000 2006 2012 2018 2024 Right: this is the time shown at the US official time.gov website at the time the most recent leap second occurred in 2016. Since most clocks can't even display a 61st second, we think that being one second off during a leap second is not such a big deal. Source: https://w.wiki/6T6X information from the GPS satellites (that’s the point of the project). The bug will occur around November 20th and 21st in 2038 and has actually already occurred twice (in 1999 and 2019), so its behaviour is well known. It’s known as the GPS rollover bug, and our feature about satellite navigation in November 2019 (siliconchip. au/Article/12083) mentioned it. In short, a 10-bit counter (allowing values from zero to 1023) is used to count the number of elapsed weeks in the GPS satellites. This counter rolls over every 19 or so years. A newer satellite protocol uses a 13-bit counter, so the updated hardware will not be affected by a rollover until 2137. Since the problematic counter affects the weeks, things such as the time of day will still be correct. So even if this bug were an issue, it would not cause problems for simple analog clocks. The worst that could happen is that the wrong daylight savings rules may be applied due to the bug. 2100 The NMEA sentences used by GPS only include the year as a two-digit number, in a pattern reminiscent of the original Millennium Bug. Naturally, this shouldn’t cause any problems until much closer to 2100. The New WiFi Time Source will produce accurate data, at least according to the NMEA standards. It will be up to the receiving circuitry to interpret siliconchip.com.au the year field as being in the correct century. Like with the GPS rollover bug, simple analog clocks do not need to know the year, so they will probably not be affected. Because 2100 is not a leap year, but 2000 is, the worst that could happen is that daylight savings changes might be applied a day early or a day late. Dealing with leap seconds UTC (which is derived from atomic clocks) is also subject to leap seconds. This is an attempt to align the time with so-called mean solar time. Mean solar time ties its noon time to when the sun is directly overhead, and can drift due to geological phenomena. The difference is due to the subtle changes in the Earth’s rotational speed. When these variations build up, leap seconds are effectively a jump in the value of UTC. When a leap second occurs, a clock might be out by up to one second until its time is adjusted. Leap seconds are not applied in a standard fashion, especially with NTP. Some servers freeze the time for a second, while others smear the time change over a longer period. Some might not apply the change at the correct time. There are proposals to eliminate leap seconds. At the moment, the equivalence between mean solar time and UTC is very close; there has not been a leap second since 2016, compared to the 1970s and 1980s when one occurred in most years. Australia's electronics magazine So, for this reason, we cannot guarantee exactly what will happen with the WiFi Time Source around the time a leap second occurs, and for around a day on either side. The time could be out by up to a second. Still, that will only be a problem if and when a leap second is required. As an aside, the reasons why the need for leap seconds comes and goes are complex but are partially due to the interaction of the Earth, Moon, Sun and other planets and bodies in the solar system. Those bodies affect the orbit of the Earth and Moon and thus influence the amount of angular momentum transferred from the Earth to the Moon due to the tides. Conclusion We think our WiFi Time Source will be a robust time source well into the future and will work correctly up until at least 2056. With some minor settings updates, it should work until at least 2100. However, be aware that other systems, especially embedded systems, might run into trouble around 2036 or, more likely, in 2038. Many small embedded devices run Linux or other systems derived from Unix and thus will potentially be affected by the 2038 bug, especially if they are no longer being supported with software updates. Keep in mind that before these bugs occur, it’s possible that WiFi or NTP might become obsolete and disappear, possibly ‘solving’ these problems in another way. SC June 2023  71