Time formatting and storage bugs

In computer science, time formatting and storage bugs are a class of software bugs which may cause time and date calculation or display to be improperly handled. These are most commonly manifestations of arithmetic overflow, but can also be the result of other issues. The most well-known consequence of bugs of this type is the Y2K problem, but many other milestone dates or times exist that have caused or will cause problems depending on various programming deficiencies.

Year 1970

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. The problem was identified and corrected before 1970. No problems due to this problem are known to have occurred. The fix generally was to expand the year to just two digits, owing to limitations of the storage media common in that era, tab cards and magnetic tape.

Year 1975

On 4 January, 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]

Year 1997

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.[2]

Year 1999

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.

9/9/99

In many programs or data sets, "9/9/99" was used as a rogue value to indicate either an unresolved date or as a terminator to indicate no further data was in the set. This raised issues upon the arrival of the actual date this represents, 9 September 1999.[3]

GPS rollover

The other problem was related to GPS devices: GPS dates are expressed as a week number and a day-of-week number, with the week number transmitted as a ten-bit value. This means that every 1,024 weeks (about 19.6 years) after 6 January 1980 (the GPS epoch), the date resets again to that date; this happened for the first time on 21 August 1999.[3] To address this concern, modernized GPS navigation messages use a 13-bit field, which only repeats every 8,192 weeks (157 years), and will not return to zero until near the year 2137.

Year 2000

Two-digit year representations

Main article: Year 2000 problem

Follow-on problems caused by certain temporary fixes to the Y2K problem will crop up at various points in the 21st century. Some programs were made Y2K-compliant by continuing to use two digit years, but picking an arbitrary year prior to which those years are interpreted as 20xx, and after which are interpreted as 19xx.[4]

For example, a program may have been changed so that it treats two-digit year values 00–68 as referring to 2000 through 2068, and values 69–99 as referring to 1969 through 1999.[5] Such a program will not be able to correctly deal with years beyond 2068.

For applications required to calculate the birth year (or other past year), such an algorithm has long been used to overcome the Year 1900 problem, but it has failed to recognise people over 100 years old.

Serial presence detect (SPD) EEPROMs

The SPD EEPROM on modern computer memory modules contains a single-byte binary-coded decimal (two digit) year-of-manufacture code at offset +93 (0x5D).[6] Due to the 18–24 month generational cycle in computer technology this should not be a problem.

Year 2001

On 9 September 2001, in Unix the number of seconds past the Unix epoch: midnight UTC, 1 January 1970 reached 1 billion. Programs that compared dates as seconds past epoch, but only had room for nine digits, failed to work correctly.

Year 2010

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.[7]

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 0016 through 0916. But the decimal number 10 is encoded in hexadecimal as 0A16 and in BCD as 1016. Thus a BCD 1016 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.[8][9]

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

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.[12]

Year 2011

Main article: Y1C Problem

Taiwan (known formally as the Republic of China (ROC)) 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.[13]

Year 2013

The Deep Impact Spacecraft lost communication with Earth in August 2013, after a clock counted 2^32 tenth-seconds after 1 January 2000.

Year 2015

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 (dead battery or a need to remove/insert a SIM card that's behind the battery in the phone). The workaround is to use the year 1987 in lieu of 2015 as a compatible leap year to display the correct week of day, date, and month on the main screen.

Year 2038

Main article: Year 2038 problem

The original implementation of the Unix operating system stored system time as a 32-bit signed integer representing the number of seconds past the Unix epoch: midnight UTC, 1 January 1970. This value will roll over on 19 January 2038. This problem has been addressed in most modern Unix and Unix-like operating systems by storing system time as a 64-bit signed integer, although individual applications, protocols, and file formats will still need to be changed as well.

DVB rollover

The Digital Video Broadcast system has an issue on 22 April 2038, when the 16 bits used to transmit Modified Julian Days used for electronic guide scheduling will restart from zero. The ETSI EN 300 368 specification mentions in Annex C that the provided MJD formulas are valid until 28 February 2100, but makes no mention of the limits imposed by the 16 bits used to transmit the resulting value.

Year 2040

Apple's Hierarchical File System (HFS) and its successor HFS Plus (HFS+) will overflow their timestamp formats. HFS+ is the default format for all of Apple's Macintosh computers and can only represent dates in the range January 1, 1904 to February 6, 2040. Apple is currently working on its Apple File System as a replacement.

Year 2042

On 17 September 2042, at 23:53:57.370496 TAI, the Time of Day Clock on the S/370 IBM mainframe and its successors, including the current zSeries, will roll over.[14] The UTC time will be a few seconds earlier, due to leap seconds.

The TOD Clock is implemented as a 64-bit count of 2−12 microsecond (0.244 ns) units, and the standard base is 1 January 1900. The actual resolution depends on the model, but the format is consistent, and will therefore roll over after 252 microseconds. Note that IBM time base is exactly 10 seconds off TAI (it was originally defined in UTC, when that was the offset from TAI).

The TOD Clock 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.

Year 2048

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.

Year 2079

Days 32,768 and 65,536

Programs that store dates as the number of days since an arbitrary date (or epoch) are vulnerable to roll-over or wrap-around effects if the values are not wide enough to allow the date values to span a large enough time range expected for the application. Signed 16-bit binary values roll over after 32,768 (215) days from the epoch date, producing negative values. Some mainframe systems experienced software failures because they had encoded dates as the number of days since 1 January 1900, which produced unexpected negative day numbers on the roll-over date of 18 September 1989. Similarly, unsigned 16-bit binary days counts overflow after 65,536 (216) days, which are truncated to zero values. For software using an epoch of 1 January 1900, this will occur on 6 June 2079.[15]

Year 2080

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 week of day, 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.

Year 2100

See also: Leap year bug

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.

Calendars on the PlayStation 2 game consoles and the Nintendo DS handheld game systems will have problems as well.

Another problem will emerge at the end of 2100-02-28, as 2100 is not a leap year, but many common implementations of the leap year algorithm are incomplete or simplified and would 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.

Year 2106

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. (This storage representation problem is independent of programs that internally store and operate on system times as 64-bit signed integer values.)

Year 2108

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.

Year 2262

The Go programming language has a UnixNano API that counts nanoseconds since 1970 as a 64-bit signed integer.[16] This value will overflow on 2262-04-11.

Year 10,000

Main article: Year 10,000 problem

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 power of 10 years have the potential for similar problems.

Year 10,001

Since Apple devices only say dates 31 December 10,000 (and more recent than 1 January AD 1), it will have problems on 1 January 10,001.

Years 32,768 and 65,536

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.

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

Far-fetched problems

Certain problematic years occur so far in the future—well beyond the likely lifespan of Earth or the Sun, 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 truly is solved for any reasonable definition of "solved".

Note: these year values are based on an average year of 365.2425 days, which matches the 4/100/400 leap year rules of the commonly used Gregorian calendar. Additional adjustments to the calendar over intervals this long are unavoidable, as the actual year is currently slightly shorter (about 365.242374 days) than assumed, the length of Earth's orbit around to the Sun changes over time (tropical years are currently becoming shorter at a rate of about .53 seconds per century), and that all of these times far exceed the likely existence of the Earth. So the year numbers should be considered approximate.

See also

References

  1. ↑ Austein, Rob. "DATE-86, or The Ghost of Tinkles Past". The Risks Digest. ACM Committee on Computers and Public Policy. Retrieved 29 December 2014.
  2. ↑ Latest News on the Date Bug
  3. 1 2 Janis L. Gogan (9 August 1999). "Applications To The Nines". InformationWeek. Retrieved 21 January 2008.
  4. ↑ Roger Deschner (21 December 2001). "Identifying and Correcting Dates with Two-Digit Years". University of Illinois at Chicago. Retrieved 19 January 2010. See "Example 1: 100 Year Fixed Window, 1973 to 2072"
  5. ↑ date – write the date and time, The Open Group Base Specifications Issue 6. IEEE Std 1003.1, 2004 Edition
  6. ↑ "JEDEC Standard No. 21-C – 4.1.2.4 – Appendix D, Rev. 1.0 : SPD's for DDR SDRAM" (PDF). Retrieved 12 May 2011.
  7. ↑ "Bank of Queensland hit by "Y2.01k" glitch". 4 January 2010.
  8. ↑ "Windows Mobile glitch dates 2010 texts 2016". 5 January 2010.
  9. ↑ "Windows Mobile phones suffer Y2K+10 bug". 4 January 2010.
  10. ↑ "Bank of Queensland vs Y2K – an update". 4 January 2010.
  11. ↑ "Error: 8001050F Takes Down PlayStation Network".
  12. ↑ "2010 Bug in Germany". 6 January 2010.
  13. ↑ Pinyin news » Taiwan's Y1C problem
  14. ↑ Dhondy, Noshir; Eckam, Hans-Peter; Jaeckel, Marcel; McDonough, Jeff; Ng, George; Packheiser, Frank; Tanguy, Bernard (1 July 2009), Server Time Protocol Planning Guide, IBM Redbooks (second ed.), IBM, ISBN 0-7384-3276-8, retrieved 8 April 2010
  15. ↑ J. R. Stockton (12 April 2009). "Critical and Significant Dates". Archived from the original on 7 September 2015. Retrieved 20 August 2009.
  16. ↑ https://golang.org/pkg/time/#Time.UnixNano
  17. ↑ Top 10 Fun Reasons why you Should Stop Using Delphi, now!
  18. ↑ http://libsnap.dom.edu/ClasPlus/ADDONS/Y2K.TXT
  19. ↑ William Porquet (15 August 2007). "Project 2038 FAQ". Retrieved 5 March 2010.
This article is issued from Wikipedia - version of the 12/1/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.