I gave a talk at Penguicon 2024 about the Epochalypse (year 2038 bug). The discussion after the event made me think I should keep at this for at least some of the next 14 years, looking at timekeeping related issues.
Mostly this is a clippings blog, with references back to original sources.
Timekeeping is complicated.
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b960e8093e7a57de98724931d17b2fa86ff1105f for the commit message.
"Ext2 users are advised to use ext4 driver to access their filesystem. The driver is fully compatible, supports filesystems without journal or extents, and also supports larger time stamps if the filesystem is created with at least 256 byte inodes."
https://www.opencompute.org/wiki/Time_Appliances_Project
Time Appliances Project (TAP) aims to provide a platform to bring together the community, discuss, standardize and share technologies and solutions across industries with the datacenter applications and datacenter network infrastructure as the main interest. The project aims to bring together the community of datacenter operators, application developers, and equipment and semiconductor companies together to enable datacenter time-sensitive applications such as consistency in distributed systems, edge computing, AR/VR and IoT. These applications will greatly benefit from high accuracy, reliable, and scalable distribution and synchronization of time.
There is an series of calls every other week with recorded presentations from learned individuals in the community, linked from these pages.
From https://developers.google.com/time/smear
Since 2008, instead of applying leap seconds to our servers using clock steps, we have "smeared" the extra second across the hours before and after each leap. The leap smear applies to all Google services, including all our APIs.
A software library for managing this is "unsmear" which converts between smeared time and unsmeared time.
https://github.com/google/unsmear
This C++ library converts precisely between timestamps in the timescale of UTC with smeared leap seconds and the unsmeared TAI and GPS timescales.
This allows smeared time to be stored and distributed exclusively, then converted to and from other timescales in applications where the smear's 11.6 ppm frequency change is consequential. No parallel time distribution systems are required, nor is any mechanism necessary for a system to record what timescale its system clock is using.
The narrative notes that this works for both positive and negative leap seconds, and avoids steps or clock discontinuities.
From Nature, 27 March 2024 https://www.nature.com/articles/d41586-024-00850-x https://doi.org/10.1038/d41586-024-00850-x
Humans’ effect on the polar ice sheets is slowing Earth’s rotation, posing challenges for its alignment with the official time standard. Two researchers discuss the science behind the slowdown and the impact it has on timekeeping.
The leap-second problem in question is the "negative leap second", which hasn't happened yet and is thus untested.
UTC is currently computed using data from about 450 atomic clocks, which are maintained in more than 80 institutions around the world. It is disseminated in real time by these time laboratories, by means such as radio or telephone signals, the Internet or optical fibre protocols, and also through GNSS signals. Since 1972, irregularities in Earth’s movement have called for 27 leap seconds to be added — at irregular intervals and with a maximum of only 6 months’ notice each time. The irony is that metrologists now face the challenge of removing a leap second from UTC for the first time, because Earth’s rotation is gradually getting faster than the time standard set by atomic clocks.
Why is the earth's rotational speed changing? Core-mantle coupling is likely.
The effects of tidal dissipation and shape adjustments have not changed appreciably since the advent of modern atomic timekeeping, but the impact of core–mantle coupling on Earth’s rotation varies on multiple timescales as a result of the fluid nature of the outer core. And herein lies the probable cause of timekeeping’s most recent dilemma: leap seconds have been required with much lower frequency since 2000 than in the previous 30 years, which indicates that Earth’s rotation rate is accelerating. Given the stability of tidal dissipation and shape-adjustment effects over this period, the main culprit must be core–mantle coupling.
The authors are Patrizia Tavella from BIPM https://www.bipm.org/en/ and Jerry Mitrovica from Harvard https://mitrovica.eps.harvard.edu .
From https://wiki.debian.org/ReleaseGoals/64bit-time as seen on 2024-04-29 :
This is now less that 15 years away and plenty of system that will have problems have already been shipped. We should stop adding to the problem. Most computing, especially computing using Debian or its derivatives, is now done on 64-bit hardware where this issue does not arise. However there is quite a lot of cost-sensitive 32-bit computing still out there, and still shipping new devices (automotive, IOT, TVs, routers, plant control, building monitoring/control, cheap Android phones). Some of that hardware will probably be running Debian or its derivatives. Other binary distros are dropping 32-bit support (RedHat/Fedora have already done so, SUSE's support is unofficial), so what is left is more likely to end up in the Debian ecosystem. Most such new hardware will be running build-from-source OSes like OpenEmbedded, or Alpine, Android, or Gentoo, but the Debian-based niche is likely to remain for some years, and some stuff built with it is likely to be in use/installed for long enough to hit Jan 2038.
Debian is primarily concerned about the armhf architecture as the one 32-bit architecture most likely to still be getting significant usage in new systems over the next decade. But i386, armel, mipsel (and hppa, hurd-i386, powerpc, m68k, and sh4 ports) are also affected. Other 32-bit architectures already use 64-bit time: x32, riscv32, arc, and loong32.
The armhf architecture is the one used by 32-bit Raspberry Pi systems, and the official Raspberry Pi OS is a Debian derivative.
For sale by Geekenspiel on eBay: https://www.ebay.com/itm/114654365152
Featured on the talk I gave at Penguicon in Ypsilanti, MI on the year 2038 problem. Thanks benny Vasquez for the photo.
https://hachyderm.io/@w8emv/112345460384500183
From https://www.whitehouse.gov/ostp/news-updates/2024/04/02/white-house-office-of-science-and-technology-policy-releases-celestial-time-standardization-policy/ dated April 2 2024:
A unified time standard—Coordinated Lunar Time (LTC)—will act as the established standard to enable cislunar operations and can be tied to Coordinated Universal Time (UTC), the primary time standard globally used to regulate clocks and time on Earth. This policy directs NASA to work with the Departments of Commerce, Defense, State, and Transportation to deliver a strategy for the implementation of LTC no later than December 31, 2026. NASA will also coordinate with other federal agencies as appropriate and international partners through existing international forums, including Artemis Accords partner nations.
More from the Guardian, https://www.theguardian.com/science/2024/apr/02/moon-nasa-coordinated-lunar-time
It’s not quite a time zone like those on Earth, but an entire frame of time reference for the moon. Because there’s less gravity on the moon, time there moves a tad more quickly – 58.7 microseconds every day – compared with on Earth. Among other things, LTC would provide a time-keeping benchmark for lunar spacecraft and satellites that require extreme precision for their missions.
It is not expected that the Moon would have daylight saving time.
Wikipedia: https://en.wikipedia.org/wiki/Timekeeping_on_the_Moon
A meme. Not my original work, forwarded to me by benny Vasquez.
"Describe your perfect date."
"Oh that's a tough one. I'd have to say YYYY-MM-DD, because when you sort it alphabetically it also sorts it chronologically."
From the the NTP (network time protocol) IETF working group comes RFC 8877 (September 2020). The authors (Mizrahi, Fabini, and Morton) use the term "wraparound" to specify the condition at the end of the time epoch.
https://datatracker.ietf.org/doc/html/rfc8877
Packet timestamps are used in various network protocols. Typical applications of packet timestamps include delay measurement, clock synchronization, and others. The following table presents a (non- exhaustive) list of protocols that use packet timestamps and the timestamp formats used in each of these protocols.
Rather than try to reproduce the table exactly in text, here is an image of it for reference to the original. NTP and PTP (precision time protocol) timestamps are described in some detail, along with several other timestamp formats used by various other protocols.
The (NTP) epoch is 1 January 1900 at 00:00 UTC.
This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2036.
The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI.
This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2106.
Dave Mills (developer of the Network Time Protocol) writes about the NTP Era and how the protocol deals with time beyond 2036.
https://www.eecis.udel.edu/~mills/y2k.html
As of early 2012 the Network Time Protocol (NTP) has been ticking over 30 years and remains the longest running, continuously operating application protocol in the Internet. There was some fear, especially in government and financial institutions, that NTP might cause an Internet meltdown upon the Millennium epoch, but those fears turned out to be groundless. However, the concern now is a possible meltdown when the unsigned 64-bit NTP timestamp rolls over in 2036. This document explores this issue together with the interpretation of the NTP timescale with respect to the Gregorian calendar.
Last update 12-May-2012 23:56 UTC