It’s fading from our collective memory, but almost thirty years ago, the global IT industry was gripped by Y2K fever. In the years leading up to the year 2000, it was observed that many of the older software systems at the time represented a date using just the last two digits of the year.
In this mode of date representation, the transition to the new century would look like the local clock had been turned backward, and that would cause poorly written software to crash or spin into an infinite loop. It was a rather obscure problem, but it was taken up in mainstream media as a sure sign of impending techno-doom, with dire predictions of jammed lifts, failing phone systems, and much more.
A lot of money and time were spent on auditing IT systems to ensure that they could handle this time transition to a new millennium without any fuss. Many companies — including the phone company I worked for at the time — called their technical staff into the office to babysit their IT systems when the local wall clock time reached midnight.
Nothing happened.
Y2K turned out to be a non-event because few programming languages — and fewer operating systems — used a local representation of the time with a two-digit year code. We may have used two-digit year codes in handwritten dates, but that was not how the date and time were handled within software stacks in most cases.
COBOL had a variant of the date in a six-digit numeric form, so that the millennium transition would cause the date to move from ‘991231’ to ‘000101’. Even so, the amount of COBOL in the world of 1999 was not exactly large, and time mostly rolled over to the new millennium without issue.
Counting time from an epoch
Far commoner at that time was an internal representation of time as the number of units of time since some defined epoch.
For example, in Excel, the time is stored as a fractional count of the number of days since 1 January 1900. The Unix operating system’s internal representation of the time is the number of seconds since 1 January 1970 (UTC). That internal representation of time meant that the millennium occurred when the internal clock counter transitioned from the value of 946,684,799 to 946,684,800. Hardly an auspicious event, nor was it one that would trigger software mayhem! Windows uses a 64-bit count of the number of milliseconds since 1 January 1601.
The Global Positioning System (GPS) counts the number of weeks since 6 January 1980 using a 10-bit counter (1,024 weeks). The last two rollovers of this counter have already happened at midnight on 21 August 1999 and 31 March 2019. It has always been within the responsibility of the GPS user to consult other sources and choose the correct current 1,024-week block for GPS applications.
A larger table of various time representations can be found on Wikipedia.
Software systems deal with time differences constantly. If software simply assumes a monotonically increasing sequence of counter values, then at rollover time, these time differences will become negative, which may cause the code to fail in surprising ways.
So, when will these various time counters roll over?
Unix
The Unix call time() is a useful system call on a generic Unix system, and returns the current time in the form of an integer timestamp (time_t integer second counter). In a 32-bit system, time_t is usually defined as a signed 32-bit integer. However, that’s not very common these days, as most modern computer platforms support a signed 64-bit integer. If the local software libraries have been updated to have 64-bit support, then the generic data type used for the seconds counter is an unsigned 64-bit integer.
When applications are compiled, the compiler will impose a uniform view of the internal data objects. A 32-bit Unix application or library still expects the kernel to return a 32-bit value, even if the kernel is running on a 64-bit architecture. This could be a problem, because even though 64-bit platforms are becoming ubiquitous in the coming years, legacy application software will continue to be used.
If you are using a 32-bit signed integer platform, or running 32-bit legacy applications and using a seconds counter with an epoch of 1 January 1970, the counter rollover will occur on 19 January 2038. An unsigned 32-bit time counter will roll over on 7 February 2106. If you are using a 64-bit representation of time, then the seconds time counter will roll on 4 December, in the year 292,277,026,596!
Windows
32-Bit Windows applications, or Windows applications defining _USE_32BIT_TIME_T, can be hit by the year 2038 problem too if they use the time_t data type.
NTP
What about the Network Time Protocol (NTP)? It synchronizes a device’s clock with several reference clocks over a network, and uses a two-part 64-bit timestamp counter to represent time for most parts of the protocol. The first 32 bits are the number of seconds since 1 January 1900, and the second 32 bits are a fractional part. This gives NTP 136 years between rollovers of the seconds counter, leading to 7 February 2036 as the first rollover event for the seconds counter.
The NTPv4 specification defines an NTP date format as a 64-bit second counter, which spans 584 billion years. It’s not clear how NTP implementations will cope with the rollover of the low-order 32 bits of the second counter, but we have about a decade to figure that out!
File systems
HFS+ timestamps are stored as an unsigned 32-bit integer representing the number of seconds since midnight, 1 January 1904 (UTC). That means that the filesystem timestamps will rollover on 5 February 2040.
FAT32 timestamps use 16 bits for the calendar date and 16 bits for the time of day, so the system can hold timestamps in the range from 1980 to 2107.
NFSv4 and ZFS use the 64-bit Unix time structure, so the rollover time is well into the future, as already noted.
Rollover times at a glance
| Unix 32-bit | 19 January 2038 |
| Unix 64-bit | 4 December 292,277,026,596 |
| Windows 32-bit | 19 January 2038 |
| Windows 64-bit | 4 December 292,277,026,596 |
| NTP | 7 February 2036 |
| HFS+ | 5 February 2040 |
| FAT32 | 31 Dec 2107 |
| NFSv4 | 4 December 292,277,026,596 |
| ZFS | 4 December 292,277,026,596 |
No unplanned drama
All this seems like a replay of the Y2K story. Older systems, which have not been refactored to run on current (64-bit) hardware platforms, will encounter one or more of the forthcoming counter rollover events in 2036, 2038, and 2040.
Yes, this requires some due diligence by operators of IT and network services to ensure that their platforms and applications are refactored as required to use 64-bit timestamps. If that preparation is done well in advance, then we should expect that February 2036, January 2038 and February 2040 will all happen without much in the way of unplanned drama!
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.