~ / topics / Related Bugs
$man related-date-bugs

Related Date Bugs

In brief: The Year 2038 problem is one of many bugs caused by a date or time counter running out or being misread. Some have already happened: Y2K, the GPS week rollovers, the 2012 leap second, and the January 2020 and January 2022 failures. Others are still to come: NTP in 2036, GPS again in 2038, old Mac disks in 2040, IBM mainframe clocks in 2042, and unsigned Unix time in 2106. This page is an index with the date, cause and impact of each, and links to the detailed pages.

Risk level Varies by entry (see table)
Status Index page, as of 2026-10-21
Last reviewed 2026-10-21

Overview

Almost every date bug comes from one of four causes:

  1. A field too small for the value: two decimal digits (Y2K), 10 bits (GPS), 32 bits (Unix, NTP, HFS+, Exchange).
  2. A window or pivot that expires: Y2K windowing (Y2K20), SNTP's 1968–2036 window, GPS receiver pivot dates.
  3. Calendar edge cases: century leap-year rules (2000, 2100, Excel's 1900) and leap seconds.
  4. Encoding confusion: decimal date values stored in binary integer fields (Y2K22) and "years since 1900" values (19100).

A related family is uptime-counter rollover. These are relative counters since boot, not calendar epochs. Arduino's millis() returns an unsigned long count of milliseconds since the program started, and the documentation says it "will overflow (go back to zero), after approximately 50 days" [16]. That is 2³² ms, about 49.7 days. Such wraps break interval and timeout logic, but they do not show that a device is exposed to 2038, and vice versa. Test them separately (see Testing-and-Detection).

Index

Bug Date (UTC) Cause Impact Risk (2038 era) Page / ref
Excel 1900 leap year 1900-02-29 (nonexistent) Lotus 1-2-3 treated 1900 as a leap year. Excel and Multiplan copied it for serial-date compatibility WEEKDAY wrong before 1900-03-01. Microsoft will not fix it because every serial date would shift by one day Low [1]
GPS week rollover #1 1999-08-21/22 10-bit week number wraps after 1,024 weeks Minor. GPS less widespread then n/a GPS-Week-Rollover [2]
Y2K 2000-01-01 Two-digit years Minor failures worldwide after about $300–850bn of remediation n/a Year-2000-Problem
Leap day 2000 2000-02-29 Century leap-year rule (÷400) not implemented Japanese weather stations and ATMs, a hotel key system n/a Year-2000-Problem [3]
"Y2K10" (2010) 2010-01-01 Chip software on bank cards could not recognise 2010 About 30 million German bank cards unusable 1–8 Jan 2010. Gemalto chips blamed n/a [4]
Leap second 2012 2012-06-30 23:59:60 Linux hrtimer bug. When the clock stepped back one second, clock_was_set() was not called, so timers fired early and looped CPU spikes on Linux servers (Java, MySQL). Reported outages at Reddit and other sites, and Qantas/Amadeus check-in delays Medium (any future leap-second or clock step) [5][6]
GPS week rollover #2 2019-04-06 23:59:42 As #1 NYC municipal network down, aircraft grounded, Australian weather balloons stopped n/a GPS-Week-Rollover
"Y2K20" pivot-year bugs 2020-01-01 Y2K windowing with pivot 20: 20 read as 1920 WWE 2K20 crashed at midnight and was patched within a day. Splunk fixed a related bug in Nov 2019. Reports of NYC parking meters rejecting cards n/a (pattern recurs) [7][8]
Y2K22 — Microsoft Exchange 2022-01-01 FIP-FS anti-malware engine stored version 2201010001 (YYMMDDhhmm) in a signed 32-bit integer (max 2,147,483,647) Exchange 2016/2019 on-premises transport queues stuck. Microsoft later released a script ("ResetScanEngineVersion") that resets the engine version Low (fixed) [9][15]
Honda/Acura clocks 2022 2022-01-01 Unconfirmed. Clocks reset to 2002 Navigation clocks wrong. Honda said it would self-correct by August 2022 Low [10]
Telstra GPS timing card 2026-07-08 After a power-supply swap, a GPS card's date reset to 2006 About 45% of Telstra mobile calls and data sessions affected. Hundreds of Triple Zero calls failed High (timing chains) GPS-Week-Rollover [11]
NTP era rollover 2036-02-07 06:28:16 Unsigned 32-bit seconds since 1900. Era not sent on the wire Clients without era logic or an RTC may jump to 1900 or the wrong era Medium NTP-Era-2036
Y2038 2038-01-19 03:14:07 Signed 32-bit seconds since 1970 Wrap to 1901-12-13. Already failing in look-ahead calculations High Year-2038-Problem
GPS week rollover #3 2038-11-20/21 As #1 (LNAV only) Receivers with stale pivots High GPS-Week-Rollover
2040: classic Mac / HFS+ 2040-02-06 06:28:15 Unsigned 32-bit seconds since 1904-01-01 HFS+ cannot represent later dates Medium Year-2106-and-Beyond [12]
2042: IBM TOD clock 2042-09-17 64-bit TOD counter (epoch 1900) wraps Conversions to time_t return 1900. Look-ahead errors already occurring Medium (mainframes) Year-2106-and-Beyond [13]
Uptime counter wrap (e.g. Arduino millis()) ~49.7 days after boot, recurring Unsigned 32-bit millisecond counter since start-up Timeouts and intervals misbehave if code compares absolute values instead of subtracting Low–Medium (embedded, long-running devices) [16]
2100 non-leap year 2100-02-29 (nonexistent) Code that applies only the "÷4" rule Off-by-one-day errors from March 2100 Low Year-2106-and-Beyond
2106: unsigned 32-bit Unix 2106-02-07 06:28:15 Unsigned 32-bit seconds since 1970 Limit of the "unsigned" 2038 workaround Low Year-2106-and-Beyond
2107: DOS/FAT dates 2107-12-31 7-bit year offset from 1980 ZIP and FAT timestamps cannot go past 2107 Low Year-2106-and-Beyond
GPS CNAV 13-bit 2137 13-bit week number Next modernised-signal rollover Low GPS-Week-Rollover
Y10K 10000-01-01 Four-digit years. 9999-12-31 sentinels DateTime.MaxValue and similar types overflow Low (sentinel misuse: Medium) Year-2106-and-Beyond

Technical details

Y2K22: why a date became a "number too big"

Microsoft's FIP-FS engine encoded its signature version as a decimal date-time, YYMMDDhhmm. On 1 January 2022 the version became 2201010001, which is larger than 2,147,483,647, the maximum signed 32-bit value. The conversion failed and the engine would not start, and logs showed Can't convert "2201010001" to long. On-premises Exchange Server 2016 and 2019 were affected. Microsoft described it as "a date check failure with the change of the new year" and "not a security-related issue". The temporary workaround was to bypass malware filtering [9]. Microsoft's later fix reset the engine version to 2112330001, which fits within the 32-bit limit [15]. This is the Y2038 limit (2³¹ − 1) reached through a different encoding. The same integer ceiling causes the Year-2038-Problem.

On "Windows 2022": This wiki could not verify a separate, widely reported Windows date-rollover bug in 2022. The 2022 incidents found were the Exchange FIP-FS failure and the Honda/Acura clocks. Both are listed above. (unverified as a separate item)

Y2K20: the expiring window

Y2K windowing (see Y2K-Remediation-and-Cost) interprets two-digit years against a pivot. New Scientist reported that about 80% of systems fixed in 1999 used windowing, and that the failures in early 2020 came from a pivot of 20 [7]. The U.S. Senate's Y2K committee had warned in February 2000 that windowed software "may encounter problems with the approach of the 'pivot year'" [14].

The 2012 leap second

Linux keeps time without leap seconds and inserts one by stepping the clock back a second. In 2007, a call to clock_was_set() was removed from that path, so the high-resolution timer subsystem was not told about the step. Timers then expired a second early: those set for less than a second fired immediately and re-armed in a loop, causing load spikes. Leap seconds were rare (the previous one was in 2008), so no regular test exercised the code [5]. Reported impacts included Reddit, Mozilla, LinkedIn and Qantas/Amadeus check-in [6].

2010: German bank cards

In January 2010, about 30 million German debit and credit cards stopped working at ATMs and point-of-sale terminals from 1 to 8 January. Card-chip software could not recognise the year 2010. Banks reprogrammed cards when customers next used them [4].

Risk & compliance notes

Detection & mitigation

Add every date in the index to clock-forward test plans. See Testing-and-Detection and the Risk-Assessment-Checklist.

See also

References

  1. Excel incorrectly assumes that the year 1900 is a leap year — Microsoft Learn.
  2. GPS Week Number Rollover — GPS.gov (archive).
  3. Leap day skips past with few problems — Computerworld, 1 Mar 2000.
  4. 30 Million German Bank Cards Almost Fixed — Robert N. Charette, IEEE Spectrum, 11 Jan 2010.
  5. Leaping seconds and looping servers — Jonathan Corbet, LWN.net, 2 Jul 2012. Root cause of the hrtimer bug.
  6. Every Second Counts: Leap Second Wreaks Havoc with Software — TechWell, Jul 2012. Affected services (seen in search).
  7. This Year's Y2K20 Bug Came Directly From 'A Lazy Fix' to the Y2K Bug — Slashdot, 12 Jan 2020, summarising New Scientist. WWE 2K20, Splunk and the 80% figure. Original: New Scientist.
  8. Year 2000 problem — Wikipedia. NYC parking meters in 2020 (secondary).
  9. Microsoft Exchange year 2022 bug in FIP-FS breaks email delivery — Lawrence Abrams, BleepingComputer, 1 Jan 2022.
  10. Time to party like it's 2002: Acura and Honda car clocks knocked back 20 years by bug — The Register, 6 Jan 2022.
  11. Telstra outage caused by failure to prioritise well-known network vulnerabilities — ABC News, 2 Sep 2026.
  12. Technical Note TN1150: HFS Plus Volume Format — Apple Developer (archive).
  13. z/TPF time_t Enhancement — IBM, TPF Users Group, Apr 2023.
  14. Y2K Aftermath – Crisis Averted: Final Committee Report — U.S. Senate Special Committee, 29 Feb 2000.
  15. Microsoft behebt Y2K22-Bug in Exchange — PC-WELT, Jan 2022. The reset script and engine version 2112330001 (German; seen in search).
  16. millis() — Arduino Language Reference. unsigned long milliseconds since the program started; overflows "after approximately 50 days".