Time formatting and storage bugs

During the 1960s, some computer programs were written using just a single digit for the year, so that 0–9 represented the years 1960–1969. It was especially easy to write programs in the COBOL language with this limitation. While many companies identified this problem in advance, some did not and outages occurred when the decade rolled over. The fix generally was to expand the year to just two digits, owing to limitations of the storage media common in that era, punch cards and magnetic tape.

On 4 January 1975, the 12-bit field that had been used for dates in the Decsystem 10 operating systems overflowed. There were numerous problems and crashes related to this bug while an alternative format was developed.[1]

The PDP-8's OS/8 operating system used

• 4 bits for the month
• 5 bits for the date therein
• 3 bits for the year.[2][3]

This was recognized when COS-310 was developed, and dates were recorded differently.[4][5]

Some mainframe programs were written to encode dates as the number of days since a 'zero date' of 1 January 1900, storing them as signed 16-bit binary integers. On 18 September 1989, these programs began to fail, the date being exactly 32,768 (2¹⁵) days since the zero date. Values on and after this day do not fit into a signed 16-bit integer, but overflow and return negative values.

The Domain/OS clock, which is based on the number of 4-microsecond units that has occurred since 1 January 1980, rolled past 47 bits on 2 November 1997, rendering unpatched systems unusable.[6]

In the last few months before the year 2000, two other date-related milestones occurred that received less publicity than the then-impending Y2K problem.

Some systems had problems once the year rolled over to 2010. This was dubbed by some in the media as the "Y2K+10" or "Y2.01k" problem.[11]

The main source of problems was confusion between hexadecimal number encoding and BCD encodings of numbers. The numbers 0 through 9 are encoded in both hexadecimal and BCD as 00₁₆ through 09₁₆. But the decimal number 10 is encoded in hexadecimal as 0A₁₆ and in BCD as 10₁₆. Thus a BCD 10₁₆ interpreted as a hexadecimal encoding erroneously represents the decimal number 16.

For example, the SMS protocol uses BCD encoding for dates, so some mobile phone software incorrectly reported dates of messages as 2016 instead of 2010. Windows Mobile was the first software reported to have been affected by this glitch; in some cases WM6 changed the date of any incoming SMS message sent after 1 January 2010 from the year 2010 to 2016.[12][13]

Other systems affected include EFTPOS terminals,[14] and the PlayStation 3 (except the Slim model).[15]

The most important such glitch occurred in Germany, where upwards of 20 million bank cards became unusable, and with Citibank Belgium, whose digipass customer identification chips stopped working.[16]

Taiwan officially uses the Minguo calendar, which considers the Gregorian year 1912 to be its year 1. Thus, the Gregorian year 2011 is the ROC year 100, its first 3-digit year.[17]

The unmanned Deep Impact spaceprobe lost communication with Earth on 11 August 2013, after a clock counted 2³² deciseconds (tenths of seconds) since 1 January 2000.[18]

Several older Samsung mobile phones with Agere chipsets (such as Samsung SGH-C170) would refuse to change dates beyond 31 December 2014; the date would automatically change to 2015, but would revert to the base date in the event of a power cycle (loss of battery power).

WWE 2K20 and Star Wars Jedi: Fallen Order would both crash on 1 January 2020, when the year rolled over. The glitches could only be circumvented by resetting the year back to 2019 until a patch was released.[19][20] Additionally, Crystal Reports 8.5 would fail to generate specific reports starting in 2020.[21]

Parkeon parking meters in New York City and other locations were unable to accept credit cards as a form of payment starting in 2020. A workaround was implemented, but required each meter to be individually updated. In New York, the meters were not expected to be fixed until 9 January.[22][23]

In Poland, 5,000 cash registers stopped printing the date out properly.[24]

SUUNTO sport smart watches showed out an error in computing week days, that was presented with a +2 step (aka: FRI rather WED, SAT rather than THU). For SUUNTO Spartan model watches, bug was fixed with firmware release 2.8.32.[25]

Samsung users reported that phones running on the latest One UI 3.0 update or Android 11 lost access to the battery and charging statistics starting in 2021. Affected devices would not report usage statistics, thus leaving those sections blank.[28][29]

During the late 1970s, on Data General Nova and Eclipse systems, World Computer Corporation (doing credit union applications) created this date format;

16-bit date field:

• 128 years = 7 bits (1900+128=2028)
• 12 months = 4 bits
• 31 days = 5 bits

Dates were directly comparable using unsigned functions.

No known instances of this format are in use today.

Some systems, like MediaTek's Nucleus OS, only go up to 31 December 2030.

Palm OS uses both signed integers with the 1970 epoch, as well as unsigned integers with the 1904 epoch, for different system functions,[30] such as for system clock, and file dates (see PDB format). While this should result in Palm OS being susceptible to the 2038 problem, Palm OS also uses a 7-bit field for storing the year value, with a different epoch counting from 1904, resulting in a maximum year of (1904+127) 2031.[31]

The Network Time Protocol has an overflow issue related to the Year 2038 problem, which manifests itself at 06:28:16 UTC on 7 February 2036, rather than 2038. The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving NTP a time scale that rolls over every 2³² seconds (136 years) and a theoretical resolution of 2⁻³² second (233 picoseconds). NTP uses an epoch of 1 January 1900. The first rollover occurs in 2036, prior to the UNIX year 2038 problem.[32][33]

Early Apple Macintosh computers store time in their real-time clocks (RTCs) and HFS filesystems as an unsigned 32-bit number of seconds since 00:00:00 on 1 January 1904. After 06:28:15 on 6 February 2040, this will wrap around to 1904.[34] HFS+, the default format for all of Apple's recent Macintosh computers, is also affected. The replacement Apple File System resolves this issue.

ProDOS for the Apple II computers only supports two-digit year numbers. To avoid Y2K issues, Apple issued a technical note stating that the year number was to represent 1940-2039.[35] Software for the platform may incorrectly display dates beginning in 2040. A third-party effort is underway to update ProDOS and application software to support years up to 2924.[36]

On 18 September 2042, the Time of Day Clock (TODC) on the S/370 IBM mainframe and its successors, including the current zSeries, will roll over.[37]

Older TODCs were implemented as a 64-bit count of 2⁻¹² microsecond (0.244 ns) units, and the standard base was 1 January 1900 UT. In July 1999 the extended TODC clock was announced, which extended the clock to the right (that is, the extended bits are less significant than the original bits). The actual resolution depends on the model, but the format is consistent, and will, therefore, roll over after 2⁵² microseconds.[37]

The TODC value is accessible to user mode programs and is often used for timing and for generating unique IDs for events.

While IBM has defined and implemented a longer (128-bit) hardware format on recent machines, which extends the timer on both ends by at least 8 additional bits, many programs continue to rely on the 64-bit format which remains as an accessible subset of the longer timer.

The ATSC system will have an issue similar to the DVB issue described above after 2048 due to its use of signed 32-bit GPS seconds that begin from 6 January 1980.

The capacity planning logic in the ERP system SAP S/4HANA supports only finish dates up to 19 January 2048 (24855 days from 1 January 1980). This concerns e.g. the production, maintenance and inspection planning.[38]

Various Texas Instruments calculators of the TI BA II Plus, TI BA II Plus Professional, TI-83, TI-84 and NSpire families support a function named dbd to calculate the number of days between dates. This function accepts dates between 1950-01-01 and 2049-12-31 only. One potential area where this will start causing problems in 2020 is in the calculation of 30-year mortgages.[39][40]

The Wii and Nintendo 3DS will rollover at the end of 31 December 2050, rolling back to 1 January 2000. Some games on those consoles that have their own calendar systems, will roll back to a different year determined by the game; such as Animal Crossing: New Leaf, which will roll back to 1 January 2012.[41]

Some (if not all) Nokia phones that run Series 40 (such as the Nokia X2-00) only supports dates up to 2079-12-31 and will refuse to change dates further than 2079-12-31. The workaround is to use the year 1996 in lieu of 2080 as a compatible leap year to display the correct day of the week, date and month on the main screen.

Systems storing the year as a two-digit value 00..99 internally only (like many RTCs) may rollover from 2079-12-31 to the IBM PC and DOS epoch of 1980-01-01.

DOS and Windows file date API and conversion functions (such as INT 21h/AH=2Ah) officially support dates up to 2099-12-31 only (even though the underlying FAT filesystem would theoretically support dates up to 2107). Hence, DOS-based operating systems as well as applications that convert other formats to the FAT/DOS format, may show unexpected behavior starting 2100-01-01.

Nintendo DS will rollover at the end of 31 December 2099, rolling back to 1 January 2000.[43]

Another problem will emerge at the end of 2100-02-28, since 2100 is not a leap year, whereas many common implementations of the leap year algorithm are incomplete or simplified, and thus will erroneously assume it to be a leap year. This would cause the date to incorrectly roll over from 2100-02-28 to 2100-02-29, instead of directly to 2100-03-01.

Many existing file formats, communications protocols, and application interfaces employ a variant of the Unix time_t date format, storing the number of seconds since the Unix Epoch (midnight UTC, 1 January 1970) as an unsigned 32-bit binary integer. This value will roll over on 7 February 2106 at 06:28:15. That is, at this time the number of seconds since 1 January 1970 is FFFF FFFF in hex.

(This storage representation problem is independent of programs that internally store and operate on system times as 64-bit signed integer values.)

The date timestamps stored in FAT filesystems, originally introduced with 86-DOS 0.42 in 1981 and carried over into MS-DOS, PC DOS, DR-DOS etc., will overflow at the end of 2107-12-31. The last modification date stamp (and with DELWATCH 2.0+ also the file deletion date stamp, and since DOS 7.0+ optionally also the last access date stamp and creation date stamp), are stored in the directory entry with the year represented as an unsigned seven bit number (0–127), relative to 1980, and thereby unable to indicate any dates in the year 2108 and beyond. The API functions defined to retrieve these dates officially only support dates up to 2099-12-31.

This will also affect the ZIP archive file format, as it uses FAT file modification timestamps internally.

GPS dates are expressed as a week number and a day-of-week number, with the week number initially using a ten-bit value and modernised GPS navigation messages using a 13-bit field. Ten bit systems would rollover every 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS epoch), and 13 bit systems rollover every 8192 weeks. 13 bit systems will rollover to zero in 2137.[7][8]

The Go programming language has a UnixNano API that counts nanoseconds since 1970 as a 64-bit signed integer.[44] This value will overflow on 2262-04-11. This is a limitation of similar nanosecond timekeeping systems, such as the Timestamp object in Python pandas,[45] C++ chrono::system_clock[46] or the QEMU timers.[47]

Microsoft Outlook uses the date 1 January, 4501 as a placeholder for "none" or "empty".[48][49]

The year 10,000 will be the first Gregorian year with five digits. Although many people at first consider this year to be so far distant that a problem of this type will never actually occur, certain classes of calculations in disciplines such as astronomy and physics already need to work with years of this magnitude and greater. These applications also have to deal with the Year zero problem. All future powers of 10 years have the potential for similar problems.

"RFC 2550 - Y10K and Beyond" discusses solutions for dealing with this problem.

Beginning 14 September 30,828, Windows will not accept dates beyond this day and on startup, Windows will complain about "invalid system time". This is because the FILETIME value in Windows, which is a 64-bit value corresponding to the number of 100-nanosecond intervals since 1 January 1601, 00:00:00.0000000 UTC, will overflow its maximum possible value on that day at 02:48:05.4775808 UTC.[50]

Programs that process years as 16-bit values may encounter problems dealing with either the year 32,768 or 65,536, depending on whether the value is treated as a signed or unsigned integer.

For the year 32,768 problem, years after 32,767 may be interpreted as negative numbers, beginning with −32,768.[51] The year 65,536 problem is more likely to manifest itself by representing the year 65,536 as the year 0.[52]

Certain problematic years occur so far in the future, well beyond the likely lifespan of the Earth, the Sun, humanity, and even past some predictions of the lifetime of the universe, that they are mainly referenced as matters of theoretical interest, jokes, or indications that a related problem is not truly solved for any reasonable definition of “solved”. The year 292,277,026,596 problem (about 2.9×10¹¹ years in the future) will occur when the 64-bit Unix time overflows at UTC 15:30:08 on Sunday, 4 December, 292,277,026,596 AD.[53][54] A similar problem will occur with 128-bit Unix time stored as nanoseconds, which will overflow in the year 5,391,559,471,918,239,498,981 AD (2^127/1000000000 seconds after the Unix epoch in 1970).

Time zones and daylight saving time can cause trouble in computer applications when:

• Communicating between places with different time zones or using the same device in a different time zone
• Daylight saving time starts and ends, especially in the fall when the same time occurs twice
• The time zone in a specific area changes or daylight saving time is adjusted, especially when there isn't enough time for software and firmware to be updated accordingly
• The time shifts less or more than 1 hour forward in the spring
• The start/end dates of summer time depend on other astronomical events
• Daylight saving time is not adopted by everyone in the same place

• Software bug
• Heisenbug
• Long Now Foundation