Time formatting and storage bugs

From Wikipedia, the free encyclopedia

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

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]

Year 1978[]

The Digital Equipment Corporation OS/8 operating system for the PDP-8 computer used only three bits for the year, representing the years 1970 to 1977.[2]

This was recognized when the later COS-310 operating system was developed, and dates were recorded differently.[3]

Year 1989[]

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 (215) 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.

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

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.

First GPS rollover[]

Main article: GPS week number rollover
See also: GPS § Timekeeping

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 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS epoch), the date resets again to that date; this happened for the first time at 23:59:47 on Saturday 21 August 1999,[5] the second time at 23:59:42 UTC on 6 April 2019, and will happen again on 20 November 2038.[6] To address this concern, modernised 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.

9/9/99[]

See also: Magic number (programming) and Magic string

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

Year 2000[]

Two-digit year representations[]

Main article: Year 2000 problem
See also: Year 1900 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.[7]

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.[8] Such a program will not be able to correctly deal with years beyond 2068.

For applications required to calculate the birth year (or another 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.

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

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

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

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

Year 2011[]

Main article: Year 2011 problem

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

Year 2013[]

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

Year 2015[]

Older Samsung mobile phones with Agere chipsets, such as Samsung SGH-C170, were unable to change dates beyond 31 December 2014.[citation needed]

Year 2019[]

Second GPS rollover[]

Main article: GPS Week Number Rollover
See also: GPS § Timekeeping

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 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS epoch), the date resets again to that date; this happened for the first time at 23:59:47 on Saturday 21 August 1999,[5] the second time at 23:59:42 UTC on 6 April 2019, and will happen again on 20 November 2038.[6] To address this concern, modernised 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.

Japanese calendar transition[]

Main article: Japanese calendar era bug

On 30 April 2019, Emperor Akihito of Japan abdicated in favor of his son Naruhito. As years in Japan are traditionally referred to by era names that correspond to the reign of each emperor, this resulted in a new era name, Reiwa (令和), following Naruhito's accession to the throne the following day. Because the previous emperor, Hirohito, died 7 January 1989 and Akihito's reign mostly corresponded with the rise in the use of computers, most software had not been tested to ensure correct behavior on an era change, while testing was further complicated by the fact that the new era name was not revealed until 1 April 2019.

Therefore, errors were expected from software that did not anticipate a new era.

Year 2020[]

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.[17][18] Additionally, Crystal Reports 8.5 would fail to generate specific reports starting in 2020.[19]

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

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

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, the bug was fixed with firmware release 2.8.32.[23]

Classic Mac OS[]

The control panel in Classic Mac OS versions 6, 7, and 8 only allows the date to be set as high as 31 December 2019, although the system is able to continue to advance time beyond that date.[24][25]

Year 2021[]

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.[26][27] Older Sony Bravia models now report invalid data when trying to set EPG reminders.[citation needed]

Year 2025[]

In Japan, some older computer systems using the Japanese calendar that have not been updated still count years according to the Shōwa era. The year 2025 corresponds in those systems to Shōwa 100, which can cause problems if the software assumes two digits for the year.[28]

Year 2028[]

Some systems store their year as a single-byte offset from 1900, which gives a range of 255 (8 bits) and allows dates up to 2155 to be safely represented. Unfortunately, not all systems use an unsigned byte: some have been mistakenly coded with a signed byte which only allows a range of 127 years, meaning that the date field in the software will be incorrect after 2027 and can cause unpredictable behaviour. Several pieces of optical disc software that operates using the ISO 9660 format are affected by this.[29]

During the late 1970s, on Data General Nova and Eclipse systems, the World Computer Corporation (doing credit union applications) created a date format with a 16-bit date field for 128 years (7 bits - note 1900+128=2028), 12 months (4 bits) and 31 days (5 bits). This allowed dates to be directly comparable using unsigned functions. Some systems, including HP 3000, still use this format, although a patch has been developed by outside consultants.[30]

Year 2031[]

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

Year 2032[]

Palm OS uses both signed integers with the 1970 epoch, as well as unsigned integers with the 1904 epoch, for different system functions,[31] 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 2031 (1904+127).[32]

Year 2036[]

See also: Network Time Protocol § Timestamps

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 232 seconds (136 years) and a theoretical resolution of 2−32 second (233 picoseconds). NTP uses an epoch of 1 January 1900. The first rollover occurs in 2036, prior to the UNIX year 2038 problem.[33][34]

Year 2038[]

Unix time rollover[]

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 00:00:00 on Thursday, 1 January 1970. This value will roll over after midnight UTC 03:14:07 on Tuesday, 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.[citation needed]

Third GPS rollover[]

Main article: GPS Week Number Rollover
See also: GPS § Timekeeping

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 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS epoch), the date resets again to that date; this happened for the first time at 23:59:47 on Saturday 21 August 1999,[5] the second time at 23:59:42 UTC on 6 April 2019, and will happen again on 20 November 2038.[6] To address this concern, modernised 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 2040[]

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 (i.e. 232-1 seconds from the epoch), this will wrap around to 1904:[35] further to this, 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.[36] Software for the platform may incorrectly display dates beginning in 2040, though a third-party effort is underway to update ProDOS and application software to support years up to 4095.[37]

Year 2042[]

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

Older TODCs were implemented as a 64-bit count of 2−12 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 252 microseconds.[38]

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.

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.

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

Year 2051[]

The Wii and Nintendo 3DS will roll over 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.[40]

Year 2061[]

The Nintendo Switch does not allow users to input any date past 2060-12-31. However, the system is still able to advance time beyond that date.[41]

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

Year 2080[]

Some (if not all) Nokia phones that run Series 40 (such as the Nokia X2-00) only support dates up to 2079-12-31, and thus will be unable to display dates after this. One workaround is to use the year 1996, 2024 or 2052 in lieu of 2080 (as compatible leap years) 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 roll over 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.

Another problem will emerge at the end of 2100-02-28, since 2100 is not a leap year. As many common implementations of the leap year algorithm are incomplete or are simplified, they will erroneously assume 2100 to be a leap year, causing the date to roll over from 2100-02-28 to 2100-02-29 instead of 2100-03-01.

The Nintendo DS and GameCube, as well as the Sony PlayStation 4 only allow users to set dates up to the year 2099. In the case of the Nintendo DS, the system will not advance time beyond 2099-12-31, where as the GameCube and PS4 will still roll over into 2100 and beyond, even in spite of the fact that users of those game consoles cannot manually input the date and time that far out.

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 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.)

Year 2108[]

The date timestamps stored in FAT filesystems, originally introduced with 86-DOS 0.42 in 25 February 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 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.

Year 2137[]

Main article: GPS Week Number Rollover
See also: GPS § Timekeeping

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 roll over every 1024 weeks (about 19.6 years) after Sunday 6 January 1980 (the GPS epoch), and 13-bit systems roll over every 8192 weeks. Thirteen-bit systems will roll over to zero in 2137.[5][6]

Year 2262[]

Some timekeeping systems count nanoseconds since 1970 using a 64-bit signed integer, which will overflow at 11 April 2262 23:47:16. The Go programming language's UnixNano API is one example.[43] Other examples include the Timestamp object in Python pandas,[44] C++ chrono::system_clock[45][failed verification – see discussion], and the QEMU timers.[46]

Years 4000 and 8000[]

While most software (including Excel, JavaScript and R) correctly recognizes 4000 and 8000 as leap years (as they are divisible by 400), SAS does not due to an unofficial "4000 year rule".

Thus, date conversions between SAS and other software will go out of sync after February 28, 4000, unless the SAS software accounts for this discrepancy.[47][48]

Year 4501[]

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

Year 10,000[]

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

"RFC 2550 - Y10K and Beyond"[51] discusses solutions for dealing with this problem. While this is one of the "April Fool" RFCs, it raises important points while dressed with a generous helping of humour.

Year 30,828[]

Beginning 14 September 30,828, Windows will not accept dates beyond this day and on startup, Windows will display an error regarding "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.[52] This is because of integer overflow.

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.

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

Year 292,277,026,596 problem[]

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×1011 years in the future) will occur when the 64-bit Unix time overflows after UTC 15:30:08 on Sunday, 4 December, 292,277,026,596 AD.[55][56]

Relative time overflow[]

Microsoft[]

In Microsoft Windows 7, Windows Server 2003, Windows Server 2008 and Windows Vista, TCP connection start information was stored in hundredths of a second, using a 32-bit unsigned integer, causing an overflow and TCP connections to fail after 497 days.[57]

Microsoft Windows 95 and Windows 98 had a problem with 2^32 millisecond rollover in a virtual device driver (VTDAPI.VXD), which caused systems to hang after 49.7 days.[58]

Boeing[]

The Boeing 787 aircraft has had at least two software issues related to time storage. In 2015, an error was reported where time was stored in hundredths of a second, using a signed 32-bit integer, and the systems would crash after 248 days.[59] In 2020, the FAA issued an airworthiness directive for a problem where, if the aircraft is not powered down completely before reaching 51 days of uptime, systems will begin to display misleading data.[60]

Arduino[]

The Arduino platform provides a relative time via the millis() function. This function returns an unsigned 32 bit value for "milliseconds since startup", which is designed to roll over every 49.71 days. By default, this is the only timing source available in the platform and programs need to take special care to handle rollovers. [61] Internally, millis() is based on counting timer interrupts. Certain powersave modes disable interrupts and therefore stop the counter from advancing during sleep. [62]

See also[]

References[]

  1. ^ Austein, Rob (2 February 1987). "DATE-86, or The Ghost of Tinkles Past". The RISKS Digest. ACM Committee on Computers and Public Policy. 4 (45). Retrieved 29 December 2014.
  2. ^ "Directory of linctape-images/os8l/ps-8-system-25.linc". OS/8 can only store dates for an 8 year period...
  3. ^ "The Digital Equipment Corporation PDP-8 : Frequently Asked Questions". COS-310, DEC's commercial operating system for the PDP-8 ... file system is almost the same as OS/8, but dates are recorded differently
  4. ^ Latest News on the Date Bug
  5. ^ a b c d e Janis L. Gogan (9 August 1999). "Applications To The Nines". InformationWeek. Archived from the original on 3 October 2008. Retrieved 21 January 2008.
  6. ^ a b c d "GPS week roll over April 6th". www.cyber.gov.au. Retrieved 10 June 2019.
  7. ^ 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"
  8. ^ date – write the date and time, The Open Group Base Specifications Issue 6. IEEE Std 1003.1, 2004 Edition
  9. ^ "Bank of Queensland hit by "Y2.01k" glitch". 4 January 2010.
  10. ^ "Windows Mobile glitch dates 2010 texts 2016". 5 January 2010.
  11. ^ "Windows Mobile phones suffer Y2K+10 bug". 4 January 2010. Archived from the original on 23 October 2013. Retrieved 3 July 2013.
  12. ^ "Bank of Queensland vs Y2K – an update". 4 January 2010. Archived from the original on 8 January 2010. Retrieved 3 July 2013.
  13. ^ "Error: 8001050F Takes Down PlayStation Network".
  14. ^ "2010 Bug in Germany". 6 January 2010.
  15. ^ Pinyin news » Taiwan's Y1C problem
  16. ^ Wallace, Malcolm (23 September 2013). "Re: [tz] Deep Impact: wrong time zone?". Time Zone Database. Archived from the original on 2 October 2013.
  17. ^ Mansoor, Saqib (1 January 2020). "WWE 2K20 Refuses To Run In 2020". SegmentNext. Retrieved 1 January 2020.
  18. ^ "Star Wars Jedi: Fallen Order and WWE 2K20 are not launching due to a "2020" bug [UPDATE]". DSOGaming. 1 January 2020. Retrieved 19 November 2020.
  19. ^ "sql - ODBC Connection / Crystal Reports". Stack Overflow. Retrieved 19 November 2020.
  20. ^ "Parking Meters Across NYC Not Accepting Credit Cards, Were Never Programmed To Work In 2020". 2 January 2020. Retrieved 19 November 2020.
  21. ^ "Archived copy". Archived from the original on 4 January 2020. Retrieved 4 January 2020.CS1 maint: archived copy as title (link)
  22. ^ Pallus, Patryk; Wczoraj 16:21; 30 452 (3 January 2020). "Wielka awaria drukarek fiskalnych. Producent naprawia urządzenia, firmy liczą straty". Business Insider (in Polish). Retrieved 4 January 2020.CS1 maint: numeric names: authors list (link)
  23. ^ "Suunto Spartan Software updates".
  24. ^ "Technical Note TN1049 Approaching the Millennium: The Mac and the Year 2000". Archived from the original on 13 November 2014. Retrieved 20 January 2020.
  25. ^ "Vintage Mac 2020 fixes". Retrieved 21 January 2020.
  26. ^ Y2K strikes back? Users report an interesting glitch in Samsung's One UI 3.0 PhoneArena
  27. ^ [Update: Jan. 02] Samsung One UI 3.0 (Android 11) update bugs & issues tracker PiunikaWeb
  28. ^ "Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication". TheGuardian.com. 25 July 2018.
  29. ^ "Years since 1900 + seven bits = breakage in 2028".
  30. ^ https://www.beechglen.com/2027-patches-release-2017-12-12/. Missing or empty |title= (help)
  31. ^ "Palm OS® Protein C/C++ Compiler Language & Library Reference" (PDF). Retrieved 12 October 2019.
  32. ^ "subject:%22Re%5C%3A Date limited to 2031%22". www.mail-archive.com. Retrieved 12 October 2019.
  33. ^ David L. Mills (12 May 2012). "The NTP Era and Era Numbering". Retrieved 24 September 2016.
  34. ^ W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). UNIX Network Programming. Addison-Wesley Professional. pp. 582–. ISBN 978-0-13-141155-5.
  35. ^ Apple Computer, Inc., Inside Macintosh, Volume II, Addison Wesley, 1985, p. 369
  36. ^ "ProDOS Dates -- 2000 and Beyond". Apple, Inc. Retrieved 6 December 2019.
  37. ^ "ProDOS 2.5". Retrieved 9 June 2021.
  38. ^ a b Lascu, Octavian; Eckam, Hans-Peter; Kozakos, George; Pereira, Paulo Vitor (June 2013), Server Time Protocol Planning Guide, IBM Redbooks (4th ed.), IBM, p. 19, ISBN 978-0738438108, retrieved 11 August 2019
  39. ^ "SAP note 2258792 (access to SAP Support Portal required)". 30 November 2018.
  40. ^ "What happens when you max out the year and set to Dec 31st 11:59 PM?". 29 June 2016. Retrieved 1 November 2020.
  41. ^ "Animal Crossing time travel". IGN. 12 April 2020. Retrieved 28 August 2021.
  42. ^ J. R. Stockton (12 April 2009). "Critical and Significant Dates". Archived from the original on 7 September 2015. Retrieved 20 August 2009.
  43. ^ "Time package - time - PKG.go.dev".
  44. ^ "Time series / Date functionality — pandas 1.3.4 documentation".
  45. ^ https://en.cppreference.com/w/cpp/chrono/system_clock
  46. ^ "Archived copy". Archived from the original on 21 January 2021. Retrieved 19 June 2021.CS1 maint: archived copy as title (link)
  47. ^ In the year 9999...., Chris Hemedinger
  48. ^ The Conversion of Date and Time Values between SAS Data Sets and Microsoft Access Database, SAS 9.4 documentation
  49. ^ "OlMarkInterval enumeration (Outlook)".
  50. ^ "Filtering Items Using Query Keywords".
  51. ^ Glassman, Steve; Manasse, Mark; Mogul, Jeffrey (April 1999). "rfc2550". datatracker.ietf.org. Retrieved 13 September 2021.
  52. ^ Thulin, Anders (6 April 2013). "Interpretation of NTFS Timestamps". Forensic Focus. Retrieved 23 July 2019.
  53. ^ Top 10 Fun Reasons why you Should Stop Using Delphi, now!
  54. ^ "Archived copy". Archived from the original on 9 February 2008. Retrieved 21 January 2008.CS1 maint: archived copy as title (link)
  55. ^ William Porquet (15 August 2007). "Project 2038 FAQ". Retrieved 5 March 2010.
  56. ^ "Date/Time Conversion Contract Language" (PDF). Office of Information Technology Services, New York (state). 19 May 2019. Retrieved 16 October 2020.
  57. ^ "All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2".
  58. ^ https://web.archive.org/web/19990508050925/http://support.microsoft.com/support/kb/articles/q216/6/41.asp
  59. ^ Edgar Alvarez (1 May 2015). "To keep a Boeing Dreamliner flying, reboot once every 248 days". Engadget. Retrieved 2 April 2020.
  60. ^ Gareth Corfield (2 April 2020). "Boeing 787s must be turned off and on every 51 days to prevent 'misleading data' being shown to pilots". The Register. Retrieved 2 April 2020.
  61. ^ https://www.eeweb.com/the-answer-to-the-arduino-millis-overflow-wraparound-question/
  62. ^ "Power - How to keep track of millis during sleep mode".

Notes[]

Retrieved from ""