ในวิทยาการคอมพิวเตอร์ข้อ จำกัด ของชนิดข้อมูลและข้อผิดพลาดของซอฟต์แวร์อาจทำให้เกิดข้อผิดพลาดในการคำนวณหรือแสดงเวลาและวันที่ โดยส่วนใหญ่แล้วมักเกิดจากค่าเกิน ขีดจำกัดทางคณิตศาสตร์ (arithmetic overflow ) แต่ก็อาจเป็นผลมาจากปัญหาอื่นๆ ได้เช่นกัน ผลกระทบที่รู้จักกันดีที่สุดคือปัญหา Y2Kแต่ยังมีเหตุการณ์สำคัญอื่นๆ อีกมากมายที่เคยหรืออาจจะก่อให้เกิดปัญหาขึ้นอยู่กับข้อบกพร่องในการเขียนโปรแกรมต่างๆ

เมื่อวันที่ 5 มกราคม 1975 ฟิลด์ 12 บิตที่ใช้สำหรับวันที่ใน ระบบปฏิบัติการ TOPS-10สำหรับคอมพิวเตอร์ DEC PDP-10เกิดข้อผิดพลาดที่เรียกว่า "DATE75" ค่าของฟิลด์นี้คำนวณโดยการนำจำนวนปีนับตั้งแต่วันที่ 1 มกราคม 1964 มาคูณด้วย 12 บวกด้วยจำนวนเดือนนับตั้งแต่เดือนมกราคม คูณด้วย 31 และบวกด้วยจำนวนวันนับตั้งแต่ต้นเดือน ค่าสูงสุดที่สามารถแสดงได้โดยใช้จำนวนเต็ม 12 บิตแบบไม่มีเครื่องหมายคือ2¹² − 1 = 4095และค่า 4095 แทนวันที่ 4 มกราคม¹⁹⁷⁵${\displaystyle (((11{\text{ ปีนับตั้งแต่ปี 1964}})\times 12)+0{\text{ เดือนนับตั้งแต่เดือนมกราคม}})\times 31)+3{\text{ วันนับตั้งแต่ต้นเดือน}}=4095}$

ดังนั้น วันที่ 4 มกราคม 1975 จึงเป็นวันที่เข้ารหัสได้ล่าสุด แพทช์ "DATE-75" เลื่อนวันที่เข้ารหัสได้ล่าสุดไปเป็นวันที่ 1 กุมภาพันธ์ 2052 ทำให้วันที่เกินกำหนดเป็นวันที่ 2 กุมภาพันธ์ 2052 โดยใช้บิตสำรอง 3 บิตจากฟิลด์อื่นในเมตาเดตาของระบบไฟล์แต่บางครั้งก็ทำให้เกิดปัญหากับซอฟต์แวร์ที่ใช้บิตเหล่านั้นเพื่อวัตถุประสงค์ของตนเอง ซอฟต์แวร์บางตัวอาจรองรับการใช้บิตเพิ่มเติมหนึ่งบิตสำหรับวันที่ แต่มีปัญหาเกี่ยวกับบิตเพิ่มเติม ซึ่งอาจส่งผลให้เกิดบั๊กในวันที่ 9 มกราคม 1986 ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]}

ระบบปฏิบัติการOS/8ของ Digital Equipment Corporation สำหรับคอมพิวเตอร์ PDP-8 ใช้ nibbleสี่บิตแบบมีเครื่องหมายเพื่อจัดเก็บจำนวนปีนับตั้งแต่ปี 1970 และสามารถแสดงได้เฉพาะปี 1970 ถึง 1977 เท่านั้น^{[ 5 ] [ 6 ]}

เรื่องนี้ได้รับการตระหนักเมื่อ ระบบปฏิบัติการ COS-310ได้รับการพัฒนา และมีการบันทึกวันที่แตกต่างกัน^{[ 7 ]}

เกม หลายเกมของ Sierra Entertainmentที่วางจำหน่ายสำหรับClassic Mac OSเริ่มค้างเมื่อเล่นในวันที่ 18 กันยายน 1993 ปัญหาในเวอร์ชัน Mac ของCreative Interpreter ของ Sierra (Mac SCI) ทำให้เกม "ค้าง" เมื่อพยายามจัดการกับความล่าช้าเนื่องจากปัญหาที่เกี่ยวข้องกับการล้นค่า Mac SCI จะพยายามใช้ข้อมูลวันที่เพื่อกำหนดระยะเวลาของความล่าช้าโดยการรับเวลาปัจจุบันเป็นวินาทีตั้งแต่ 1 มกราคม 1904 ซึ่งเป็นยุค Macintosh และหารด้วย 12 ชั่วโมง การหารนี้ประมวลผลโดยMotorola 68000และจะไม่เกิดขึ้นหากตรวจพบการล้นค่าเนื่องจากการหาร แต่ Mac SCI จะยังคงดำเนินการต่อไปโดยไม่คำนึงถึงราวกับว่าการหารได้เกิดขึ้นแล้ว ในที่สุดจะส่งผลให้ความล่าช้าหนึ่งวินาทีถูกมองว่าเป็นความล่าช้า 18 ชั่วโมง และอื่นๆ Sierra ได้ออกแพทช์ชื่อ MCDATE ที่แก้ไขปัญหานี้ได้เกือบ 14 ปี^{[ 8 ] [ 9 ]}

ใน ระบบปฏิบัติการ Domain/OSของApollo Computerเวลาสัมบูรณ์จะถูกจัดเก็บเป็นจำนวนเต็ม 48 บิตแบบมีเครื่องหมาย ซึ่งแสดงถึงจำนวนหน่วย 4 ไมโครวินาที นับตั้งแต่วันที่ 1 มกราคม พ.ศ. 2523 ค่านี้เกิดการล้นในวันที่ 2 พฤศจิกายน พ.ศ. 2540 ทำให้ระบบที่ไม่ได้แก้ไขใช้งานไม่ได้^{[ 5 ] [ 10 ]}

ในช่วงไม่กี่เดือนก่อนปี 2000 มีเหตุการณ์สำคัญที่เกี่ยวข้องกับวันที่อีกสองเหตุการณ์เกิดขึ้น ซึ่งได้รับความสนใจจากสื่อไม่มากเท่ากับปัญหา Y2K ที่กำลังจะเกิดขึ้นในขณะนั้น

วันที่ของ GPS จะแสดงเป็นหมายเลขสัปดาห์และหมายเลขวันในสัปดาห์ โดยหมายเลขสัปดาห์จะถูกส่งเป็นค่า 10 บิตซึ่งหมายความว่าทุกๆ 1,024 สัปดาห์ (ประมาณ 19.6 ปี) หลังจากวันอาทิตย์ที่ 6 มกราคม 1980 ( ยุค GPS ) วันที่จะถูกรีเซ็ตเป็นวันที่นั้นอีกครั้ง เหตุการณ์นี้เกิดขึ้นครั้งแรกเวลา 23:59:47 ในวันที่ 21 สิงหาคม 1999 ^{[ 11 ]}ครั้งที่สองเวลา 23:59:42 UTCในวันที่ 6 เมษายน 2019 และจะเกิดขึ้นอีกครั้งในวันที่ 20 พฤศจิกายน 2038 ^{[ 12 ]}เพื่อแก้ไขปัญหานี้ ข้อความนำทาง GPS ที่ทันสมัยจะใช้ฟิลด์ 13 บิต ซึ่งจะซ้ำกันทุกๆ 8,192 สัปดาห์ (157 ปี) และจะไม่กลับเป็นศูนย์จนกว่าจะถึงปี 2137 ^{[ 5 ] [ 13 ]}

โปรแกรมหรือชุดข้อมูลเก่าจำนวนมากใช้ "9/9/99" เป็นค่าผิดปกติเพื่อระบุวันที่ที่ยังไม่ได้รับการแก้ไข หรือเป็นตัวสิ้นสุดเพื่อระบุว่าไม่มีข้อมูลเพิ่มเติมในชุดข้อมูล ซึ่งทำให้ระบบจำนวนมากล่มเมื่อถึงวันที่จริงที่ค่านี้แสดง: 9 กันยายน 1999 ^{[ 5 ] [ 11 ]}

คำว่า ปัญหาปี 2000 หรือเรียกสั้น ๆ ว่า Y2K หมายถึงข้อผิดพลาดทางคอมพิวเตอร์ที่อาจเกิดขึ้นเกี่ยวกับการจัดรูปแบบและการจัดเก็บข้อมูลปฏิทินสำหรับวันที่ในปี 2000 และหลังจากนั้น โปรแกรมหลายโปรแกรมแสดงปีสี่หลักโดยใช้เพียงสองหลักสุดท้าย ทำให้ปี 2000 แยกไม่ออกจากปี 1900 ความไม่สามารถของระบบคอมพิวเตอร์ในการแยกแยะวันที่ได้อย่างถูกต้องนั้น อาจส่งผลให้โครงสร้างพื้นฐานทั่วโลกสำหรับอุตสาหกรรมที่พึ่งพาคอมพิวเตอร์ล่มสลายได้

สำหรับแอปพลิเคชันที่ต้องการคำนวณปีเกิด (หรือปีอื่นในอดีต) อัลกอริทึมดังกล่าวถูกนำมาใช้เพื่อแก้ปัญหาปี ค.ศ. 1900 มานานแล้ว แต่ไม่สามารถระบุตัวตนของผู้ที่มีอายุมากกว่า 100 ปีได้

ระบบที่ใช้สตริงตัวเลขเก้าหลักในการบันทึกเวลาเป็นวินาทีนับตั้งแต่ยุค Unixมีปัญหาในการรายงานเวลาที่เกินกว่าหนึ่งในพันล้านวินาทีหลังจากยุค Unix ในวันที่ 9 กันยายน พ.ศ. 2544 เวลา 01:46:40 ("พันล้านปี") ปัญหาดังกล่าวไม่ได้แพร่หลาย^{[ 5 ] [ 14 ]}

เกมของ Sierra Entertainment สำหรับClassic Mac OSที่ได้รับการแก้ไขด้วยโปรแกรม MCDATE หรือวางจำหน่ายในภายหลังโดยมีการแก้ไขในตัว จะเริ่มค้างในวันที่ 28 พฤษภาคม 2550 เช่นเดียวกับ ปัญหา ในปี 1993ปัญหานี้เกิดจากปัญหาใน Mac SCI เมื่อพยายามใช้ข้อมูลวันที่เพื่อกำหนดระยะเวลาการหน่วงเวลา โปรแกรมที่มีการแก้ไข MCDATE จะค้างเนื่องจาก Mac SCI จะนำจำนวนวินาทีปัจจุบันนับตั้งแต่ยุค Macintoshในวันที่ 1 มกราคม 1904 ลบด้วย 432,000,000 วินาที จากนั้นหารด้วย 12 ชั่วโมงผ่าน Motorola 68000 เพื่อกำหนดระยะเวลาการหน่วงเวลา ในวันที่ 28 พฤษภาคม 2550 Motorola 68000 ไม่สามารถหารได้อีกครั้งเนื่องจากการป้องกันการล้น ซึ่ง Mac SCI ไม่สนใจ^{[ 8 ]}

บางระบบมีปัญหาเมื่อเปลี่ยนปีเป็นปี 2010 สื่อบางแห่งเรียกปัญหานี้ว่า "ปัญหา Y2K+10" หรือ "Y2.01k" ^{[ 15 ]}

ปัญหาหลักเกิดจากความสับสนระหว่างการเข้ารหัสเลขฐานสิบหกและ การเข้ารหัสเลขใน ระบบ BCDตัวเลข 0 ถึง 9 ถูกเข้ารหัสทั้งในระบบฐานสิบหกและ BCD เป็น 00 ₁₆ถึง 09 ₁₆แต่เลขฐานสิบ 10 ถูกเข้ารหัสในระบบฐานสิบหกเป็น 0A ₁₆และในระบบ BCD เป็น 10 ₁₆ดังนั้น BCD 10 ₁₆ที่ถูกตีความว่าเป็นการเข้ารหัสฐานสิบหกจึงแสดงค่าผิดพลาดเป็นเลขฐานสิบ 16

ตัวอย่างเช่น โปรโตคอล SMS ใช้การเข้ารหัส BCD สำหรับวันที่ ดังนั้นซอฟต์แวร์โทรศัพท์มือถือบางตัวจึงรายงานวันที่ของข้อความผิดพลาดเป็นปี 2016 แทนที่จะเป็นปี 2010 Windows Mobileเป็นซอฟต์แวร์แรกที่มีรายงานว่าได้รับผลกระทบจากข้อผิดพลาดนี้ ในบางกรณี WM6 เปลี่ยนวันที่ของข้อความ SMS ขาเข้าใดๆ ที่ส่งหลังจากวันที่ 1 มกราคม 2010 จากปี 2010 เป็นปี 2016 ^{[ 5 ] [ 16 ] [ 17 ]}

ความผิดพลาดที่เห็นได้ชัดที่สุดเกิดขึ้นในเยอรมนี ซึ่งบัตรธนาคารกว่า 20 ล้านใบไม่สามารถใช้งานได้ และกับซิติแบงก์เบลเยียม ซึ่งชิประบุตัวตนลูกค้าหยุดทำงาน^{[ 18 ]}

ระบบอื่นๆ ที่ได้รับผลกระทบ ได้แก่เครื่องEFTPOS ^{[ 19 ]}และPlayStation 3 (ยกเว้นรุ่น Slim) ^{[ 20 ]}

PlayStation 3ของ Sony ถือว่าปี 2010 เป็นปีอธิกสุรทิน อย่างไม่ถูกต้อง ดังนั้นวันที่ 29 กุมภาพันธ์ 2010 ซึ่งไม่มีอยู่จริง จึงแสดงเป็นวันที่ 1 มีนาคม 2010 ทำให้เกิด ข้อผิดพลาด ของโปรแกรม^{[ 5 ] [ 21 ]}

ไต้หวันใช้ปฏิทินหมิงกัว อย่างเป็นทางการ ซึ่งถือว่า ปี เกรกอเรียน 1912 เป็นปีที่ 1 ดังนั้น ปีเกรกอเรียน 2011 จึงเป็นปีที่ 100 ของสาธารณรัฐจีน ซึ่งเป็นปี 3 หลักแรก^{[ 5 ] [ 22 ]}ทำให้ปีดังกล่าวปรากฏเป็น 1911 (ปีที่ 0) หากใช้การแสดงผลแบบ 2 หลัก

ยาน สำรวจอวกาศ Deep Impactสูญเสียการติดต่อกับโลกเมื่อวันที่ 11 สิงหาคม 2556 เนื่องจากปัญหาการติดแท็กเวลา โดยวันที่ถูกจัดเก็บเป็นจำนวนเต็ม 32 บิตที่ไม่มีเครื่องหมาย ซึ่งนับจำนวนเศษส่วนของวินาทีตั้งแต่ 1 มกราคม 2543 ^{[ 23 ]}

ในปี 2019 เกิดการเปลี่ยนหมายเลขสัปดาห์ของ GPS ครั้งที่สอง กล้องโทรทัศน์แบบคอมพิวเตอร์ ของ Meadeที่มี GPS เช่น LX200GPS ไม่สามารถระบุตำแหน่งของตัวเองได้อีกต่อไป ทำให้ไม่สามารถปรับแนวหรือค้นหาวัตถุทางดาราศาสตร์ได้ Meade จึงออกเฟิร์มแวร์เวอร์ชัน 4.2k ที่แก้ไขปัญหา แต่ก็ทำให้เกิดข้อบกพร่องใหม่ๆ ขึ้นมากมาย ต่อมาจึงออกเวอร์ชัน 4.2l (ตัวL ตัวเล็ก มักสับสนกับตัวI ตัวใหญ่ ) เพื่อแก้ไขปัญหาดังกล่าว แต่ก็มีการเปลี่ยนแปลงที่ไม่สามารถอธิบายได้อีก บริษัทภายนอก StarPatch ได้ปล่อยเฟิร์มแวร์เวอร์ชัน 4.2g ที่ถูกดัดแปลงออกมาโดยไม่คิดค่าใช้จ่ายเพื่อแก้ไขปัญหาเหล่านี้

เมื่อวันที่ 30 เมษายน 2562 จักรพรรดิอากิฮิโตะแห่งญี่ปุ่นทรงสละราชสมบัติให้แก่พระโอรสนารุฮิโตะเนื่องจากในญี่ปุ่นนั้นปีต่างๆ จะถูกเรียกตามชื่อยุคสมัยซึ่งสอดคล้องกับการครองราชย์ของจักรพรรดิแต่ละพระองค์ จึงทำให้เกิดชื่อยุคสมัยใหม่ว่าเรวะ(令和)ตามมาหลังจากที่นารุฮิโตะขึ้นครองราชย์ในวันถัดมา เนื่องจากจักรพรรดิฮิโรฮิโตะเสด็จสวรรค์เมื่อวันที่ 7 มกราคม 2532 และรัชสมัยของอากิฮิโตะส่วนใหญ่ตรงกับช่วงที่การใช้คอมพิวเตอร์เฟื่องฟู ซอฟต์แวร์ส่วนใหญ่จึงยังไม่ได้ถูกทดสอบเพื่อให้แน่ใจว่าทำงานได้อย่างถูกต้องเมื่อมีการเปลี่ยนยุคสมัย อีกทั้งการทดสอบยังซับซ้อนมากขึ้นเนื่องจากชื่อยุคสมัยใหม่ไม่ได้ถูกเปิดเผยจนกระทั่งวันที่ 1 เมษายน 2562 ดังนั้นจึงคาดว่าจะเกิดข้อผิดพลาดจากซอฟต์แวร์ที่ไม่ได้คาดการณ์ถึงยุคสมัยใหม่

เกมวิดีโอWWE 2K20และStar Wars Jedi: Fallen Orderต่างก็เกิดข้อผิดพลาดในวันที่ 1 มกราคม 2020 เมื่อปีใหม่มาถึง ข้อผิดพลาดเหล่านี้สามารถแก้ไขได้โดยการรีเซ็ตปีกลับไปเป็นปี 2019 จนกว่าจะมีการปล่อยแพทช์^{[ 24 ] [ 25 ]}นอกจากนี้Crystal Reports 8.5จะไม่สามารถสร้างรายงานเฉพาะบางรายการได้ตั้งแต่ปี 2020 เป็นต้นไป^{[ 26 ]}

มิเตอร์จอดรถ Parkeonในนครนิวยอร์กและสถานที่อื่นๆ ไม่สามารถรับบัตรเครดิตเป็นวิธีการชำระเงินได้ตั้งแต่ปี 2020 มีการนำวิธีแก้ปัญหามาใช้ แต่ต้องอัปเดตมิเตอร์แต่ละตัวแยกกัน ในนิวยอร์ก คาดว่าจะซ่อมมิเตอร์เสร็จในวันที่ 9 มกราคม^{[ 27 ] [ 28 ]}

ในโปแลนด์เครื่องบันทึกเงินสด 5,000 เครื่องหยุดพิมพ์วันที่อย่างถูกต้อง^{[ 29 ]}

นาฬิกาสมาร์ทวอทช์ Suunto Sport แสดงข้อผิดพลาดในการคำนวณวันในสัปดาห์ โดยแสดงวันที่ล่วงหน้าไปสองวันจากวันที่จริง (เช่น ศุกร์ แทนที่จะเป็นพุธ เสาร์ แทนที่จะเป็นพฤหัสบดี) สำหรับนาฬิการุ่น Suunto Spartan ข้อบกพร่องนี้ได้รับการแก้ไขแล้วในเฟิร์มแวร์เวอร์ชัน 2.8.32 ^{[ 30 ]}

แผงควบคุมใน Mac OS รุ่นคลาสสิกเวอร์ชัน 6, 7 และ 8 อนุญาตให้ตั้งวันที่ได้สูงสุดเพียง 31 ธันวาคม 2019 เท่านั้น แม้ว่าระบบจะสามารถเลื่อนเวลาไปข้างหน้าเกินกว่าวันที่ดังกล่าวได้ก็ตาม^{[ 5 ] [ 31 ] [ 32 ]}

Microsoft Schedule+ เวอร์ชัน 1.0 (เวอร์ชันที่รวมอยู่ในเวอร์ชัน 3.0 ของไคลเอนต์อีเมลMicrosoft Mail ) ปฏิเสธที่จะทำงานกับปีที่มากกว่าปี 2020 หรือหลังจากนั้น เนื่องจากโปรแกรมได้รับการออกแบบให้ทำงานภายในกรอบเวลา 100 ปี ตั้งแต่ปี 1920 ถึง 2019 ดังนั้น วันที่จึงสามารถตั้งได้สูงสุดเพียง 31 ธันวาคม 2019 เท่านั้น Microsoft ระบุว่านี่เป็นการออกแบบโดยเจตนา^{[ 33 ]}

ผู้ใช้ Samsung รายงานว่าโทรศัพท์ที่ใช้การอัปเดต One UI 3.0หรือAndroid 11ไม่สามารถเข้าถึงสถิติแบตเตอรี่และการชาร์จได้ตั้งแต่ปี 2021 อุปกรณ์ที่ได้รับผลกระทบจะไม่รายงานสถิติการใช้งาน ทำให้ส่วนเหล่านั้นว่างเปล่า^{[ 34 ] [ 35 ]}

วันที่ที่จัดเก็บในรูปแบบ yymmddHHMM ที่แปลงเป็นจำนวนเต็ม 32 บิตแบบมีเครื่องหมายเกิดการล้นในวันที่ 1 มกราคม 2022 เนื่องจาก2 ³¹ = 2147483648ส่วนประกอบการสแกนมัลแวร์ของMicrosoft Exchange ได้รับผลกระทบอย่างเห็นได้ชัด โดยดูเหมือนว่าจะใช้สำหรับการตรวจสอบทางคณิตศาสตร์เพื่อกำหนดการอัปเดตล่าสุด^{[ 36 ] [ 37 ]}

รถยนต์ ฮอนด้าและอะคูร่าที่ผลิตระหว่างปี 2004 ถึง 2012 ที่มี ระบบ นำทาง GPSแสดงปีผิดพลาดเป็นปี 2002 ปัญหานี้เกิดจากการล้นของช่วงเวลา GPS ^{[ 38 ] [ 39 ]}ปัญหาได้รับการแก้ไขเมื่อวันที่ 17 สิงหาคม 2022 ^{[ 40 ]}

เครื่องอ่านบัตรชำระเงินที่ปั๊มน้ำมันในนิวซีแลนด์ไม่สามารถจัดการกับปีอธิกสุรทินได้และไม่สามารถจ่ายน้ำมันเบนซินได้อย่างถูกต้อง^{[ 41 ]}

เกมวิดีโอสองเกม ได้แก่EA Sports WRCและTheatrhythm Final Bar Lineก็ประสบปัญหาที่เกี่ยวข้องกับปีอธิกสุรทินเช่นกัน โดยเกมแรกเกิดข้อผิดพลาดขณะพยายามโหลดเกม และเกมหลังแจ้งว่าข้อมูลการบันทึกเสียหาย ทั้งสองเกมต้องตั้งค่าเป็นวันที่ 1 มีนาคม 2024 จึงจะใช้งานได้อย่างถูกต้อง^{[ 42 ] [ 43 ] [ 44 ]}

ในเดือนธันวาคม พ.ศ. 2567 พบข้อบกพร่องที่มีอายุ 30 ปีในHCL Notes ทุกเวอร์ชัน เมื่อเซิร์ฟเวอร์เริ่มต้นในวันที่ 13 ธันวาคม พ.ศ. 2567 หรือหลังจากนั้น ข้อผิดพลาดดังกล่าวจะทำให้เราเตอร์อีเมลไม่สามารถโหลดการกำหนดค่าได้ ส่งผลให้ไม่มีการส่งอีเมล แพตช์ถูกปล่อยออกมาในวันถัดไปสำหรับเวอร์ชันที่รองรับทั้งหมด^{[ 45 ]}

ในญี่ปุ่น ระบบคอมพิวเตอร์รุ่นเก่าบางระบบที่ใช้ปฏิทินญี่ปุ่นซึ่งไม่ได้อัปเดตยังคงนับปีตามยุคโชวะในระบบเหล่านั้น ปี 2025 จะตรงกับยุคโชวะที่ 100 ซึ่งอาจทำให้เกิดปัญหาได้หากซอฟต์แวร์ถือว่าปีมีตัวเลขสองหลัก^{[ 46 ]}

ในสเปน รถไฟ Talgo AVRIL ทุก ขบวนหยุดให้บริการในวันที่ 1 มกราคม 2025 เนื่องจากข้อผิดพลาดในการจัดการข้อมูลในโมดูลชาร์จแบตเตอรี่ ทำให้เกิดความล่าช้าและการยกเลิกเที่ยวรถ เนื่องจากผู้โดยสารถูกย้ายไปยังรถไฟขบวนอื่น^{[ 47 ] [ 48 ]}มีการแก้ไขปัญหาในวันถัดไป ทำให้การให้บริการกลับมาเป็นปกติ^{[ 49 ]}

บั๊กในdateคำสั่งจากRustuutilsซึ่งเป็นการเขียนใหม่ของGNU Core Utilitiesทำให้การอัปเดตอัตโนมัติในUbuntu 25.10หยุดทำงาน^{[ 50 ] [ 51 ]}

เวลาของระบบบน เครื่องคอนโซล Xbox 360สามารถเลื่อนไปข้างหน้าได้จนถึงเวลา 23:59 น. ของวันที่ 31 ธันวาคม 2025 เท่านั้น ระบบจะยังคงเลื่อนเวลาต่อไปจนถึงปี 2026 และหลังจากนั้นผ่านการเชื่อมต่อXbox Live ^{[ 52 ]}อย่างไรก็ตาม ผู้ใช้ไม่สามารถตั้งวันที่ของระบบเกินกว่าจุดนี้ได้เนื่องจากข้อจำกัดของซอฟต์แวร์ภายใน แดชบอร์ด ของMicrosoft ^{[ 53 ]}

ระบบเก่าบางระบบจัดเก็บปีเป็นค่าชดเชยไบต์เดียวจากปี 1900 ซึ่งให้ช่วง 255 (8 บิต) และอนุญาตให้แสดงวันที่ได้ถึงปี 2155 อย่างปลอดภัย อย่างไรก็ตาม ไม่ใช่ทุกระบบที่ใช้ ไบต์ ที่ไม่มีเครื่องหมายบางระบบถูกเขียนโค้ดผิดพลาดด้วยไบต์ที่มีเครื่องหมายซึ่งอนุญาตให้มีช่วงเพียง 127 ปีเท่านั้น หมายความว่าฟิลด์วันที่ในซอฟต์แวร์จะไม่ถูกต้องหลังจากปี 2027 และอาจทำให้เกิดพฤติกรรมที่ไม่สามารถคาดเดาได้ ซอฟต์แวร์แผ่นดิสก์ออปติคัลหลายชิ้นที่ทำงานโดยใช้ รูปแบบ ISO 9660ได้รับผลกระทบจากเรื่องนี้^{[ 54 ]}

ในช่วงปลายทศวรรษ 1970 บนระบบ Data General Nova และ Eclipse บริษัท World Computer Corporation (ซึ่งกำลังดำเนินการแอปพลิเคชันสหกรณ์เครดิตยูเนียน) ได้สร้างรูปแบบวันที่ที่มีฟิลด์วันที่ 16 บิต โดยใช้ 7 บิตสำหรับปี 4 บิตสำหรับเดือน และ 5 บิตสำหรับวัน ซึ่งทำให้สามารถเปรียบเทียบวันที่ได้โดยตรงโดยใช้ฟังก์ชันที่ไม่มีเครื่องหมาย ระบบบางระบบ รวมถึงHP 3000ยังคงใช้รูปแบบนี้อยู่ แม้ว่าจะมีการพัฒนาแพทช์โดยที่ปรึกษาภายนอกแล้วก็ตาม^{[ 55 ]}

Palm OSใช้ทั้ง จำนวนเต็มที่ มีเครื่องหมายพร้อมยุค 1970 และจำนวนเต็มที่ไม่มีเครื่องหมายพร้อมยุค 1904 สำหรับฟังก์ชันระบบต่างๆ^{[ 56 ]}เช่น นาฬิการะบบ และวันที่ของไฟล์ (ดูรูปแบบ PDB ) แม้ว่าสิ่งนี้ควรจะทำให้ Palm OS มีความเสี่ยงต่อปัญหา 2038แต่ Palm OS ยังใช้ฟิลด์ 7 บิตสำหรับจัดเก็บค่าปี โดยมียุคที่แตกต่างกันนับจากปี 1904 ส่งผลให้ปีสูงสุดคือ 2031 ซึ่งห่างจากปี 1904 127 ปี^{[ 57 ]}

โปรโตคอลเวลาเครือข่าย (NTP) มีปัญหาโอเวอร์โฟลว์ที่เกี่ยวข้องกับปัญหาปี 2038ซึ่งปรากฏขึ้นเวลา 06:28:16 UTC ในวันที่ 7 กุมภาพันธ์ 2036 แทนที่จะเป็นปี 2038 ไทม์สแตมป์ 64 บิตที่ NTP ใช้ประกอบด้วยส่วน 32 บิตสำหรับวินาทีและส่วน 32 บิตสำหรับเศษส่วนของวินาที ทำให้ NTP มีมาตราเวลาที่หมุนเวียนทุกๆ 2³² ^{วินาที} (136 ปี) และความละเอียดเชิงทฤษฎีที่ 2⁻³² ^{วินาที} (2³³ พิโควินาที) NTP ใช้ยุคเริ่มต้นที่ 1 มกราคม 1900 การหมุนเวียนครั้งแรกเกิดขึ้นในปี 2036 ก่อนปัญหาปี 2038 ของ UNIX ^{[ 5 ] [ 58 ] [ 59 ]}

ปัญหาเดียวกันนี้ยังส่งผลกระทบต่อการใช้งาน LISP บางส่วนด้วย^{[ 60 ]}

ระบบปฏิบัติการ Unixรุ่นดั้งเดิมจัดเก็บเวลาของระบบเป็นจำนวนเต็มแบบมีเครื่องหมาย 32 บิตซึ่งแสดงจำนวนวินาทีที่ผ่านไปนับตั้งแต่ยุค Unix (1 มกราคม 1970, 00:00:00 UTC) ค่านี้จะวนกลับไปเป็น ^ค่าเดิมหลังจากวันที่ 19 มกราคม 2038, 03:14:07 UTC ซึ่งเท่ากับ2³¹ − 1 = 2,147,483,647วินาที นับตั้งแต่ยุค Unix ปัญหานี้ได้รับการแก้ไขแล้วในระบบปฏิบัติการ Unix และ ระบบปฏิบัติการ ที่คล้าย Unix ในปัจจุบันส่วนใหญ่ โดยใช้จำนวนเต็มแบบมีเครื่องหมาย 64 บิต แม้ว่าแอปพลิเคชัน โปรโตคอล และรูปแบบไฟล์แต่ละรายการจะต้องได้รับการเปลี่ยนแปลงด้วยเช่นกัน

เช่นเดียวกับปัญหาการเปลี่ยนเวลาของ Unix เวอร์ชัน 32 บิตgmtimeในไลบรารีรันไทม์ C บน Windows ก็มีปัญหาที่คล้ายกัน^{[ 61 ]}

ปัญหาดังกล่าวได้ปรากฏให้เห็นแล้วในOracle Access Manager เวอร์ชัน 10.1.4.3 สำหรับ Windows คอมโพเนนต์ Identity Console จะตั้งค่าคุกกี้ที่มี ค่ากำหนด UIโดยมีวันหมดอายุ 500,000,000 วินาทีในอนาคต (ประมาณ 16 ปี) ซึ่งเกินวันที่ 19 มกราคม 2038 ดังนั้นจึงเกิดข้อยกเว้นสำหรับกิจกรรมการค้นหาบางอย่างหลังจากเวลา 02:20:48 UTC ในวันที่ 17 มีนาคม 2022 เนื่องจากฟังก์ชัน gmtime_r() ไม่สามารถแปลงตัวเลขที่ให้มาเป็นวันที่เพื่อเขียนลงในคุกกี้ได้^{[ 62 ]}แม้ว่าซอฟต์แวร์จะมีอายุมากแล้ว (18 มิถุนายน 2009) แต่ Oracle ก็ได้ออกแพทช์หมายเลข 33983548 ในวันที่ 6 เมษายน 2022

การเปลี่ยนหมายเลขสัปดาห์ครั้งที่สาม ของระบบ GPS จะเกิดขึ้นในวันที่ 20 พฤศจิกายน 2038 เวลา 23:59:37 UTC

คอมพิวเตอร์Apple Mac จนถึง macOS X Snow Leopardจะจัดเก็บเวลาในนาฬิกาเรียลไทม์ (RTC) และระบบไฟล์HFS เป็นจำนวนวินาที 32 บิตที่ไม่มีเครื่องหมาย นับตั้งแต่เวลา 00:00:00 ของวันที่ 1 มกราคม 1904 หลังจากเวลา 06:28:15 ของวันที่ 6 กุมภาพันธ์ 2040 (เช่น 2 ³² − 1วินาทีจากยุคเริ่มต้น) เวลาจะวนกลับไปที่ปี 1904 ^{[ 5 ] [ 63 ]}นอกจากนี้HFS+ซึ่งเดิมเป็นระบบไฟล์เริ่มต้นสำหรับคอมพิวเตอร์ Apple ส่วนใหญ่ก็ได้รับผลกระทบเช่นกันApple File Systemซึ่งมาแทนที่ HFS และ HFS+ แก้ไขปัญหานี้ได้

ProDOS ซึ่งทำงานบน คอมพิวเตอร์ Apple IIรองรับเฉพาะตัวเลขปีสองหลักเท่านั้น เพื่อหลีกเลี่ยงปัญหา Y2K Apple ได้ออกบันทึกทางเทคนิคโดยระบุว่าตัวเลขปีดังกล่าวหมายถึงปี 1940–2039 ^{[ 64 ]}ซอฟต์แวร์สำหรับแพลตฟอร์มอาจแสดงวันที่เริ่มต้นในปี 2040 อย่างไม่ถูกต้อง แม้ว่าจะมีความพยายามจากบุคคลที่สามในการอัปเดต ProDOS และซอฟต์แวร์แอปพลิเคชันเพื่อรองรับปีได้ถึง 4095 ^{[ 65 ]}

ในวันที่ 18 กันยายน พ.ศ. 2585 นาฬิกาเวลาประจำวัน (TODC) บนเมนเฟรมIBM System/370และรุ่นต่อๆ มา รวมถึง ซีรี่ส์ IBM Z ในปัจจุบัน จะเปลี่ยนเวลา^{[ 5 ] [ 66 ]}

TODC รุ่นเก่าถูกใช้งานในรูปแบบการนับ 64 บิตของหน่วย 2 ⁻¹²ไมโครวินาที (0.244 ns) และฐานมาตรฐานคือ 1 มกราคม 1900 UTในเดือนกรกฎาคม 1999 ได้มีการประกาศนาฬิกา TODC แบบขยาย ซึ่งขยายนาฬิกาไปทางขวา (นั่นคือ บิตที่ขยายออกไปมีความสำคัญน้อยกว่าบิตดั้งเดิม) ความละเอียดที่แท้จริงขึ้นอยู่กับรุ่น แต่รูปแบบมีความสม่ำเสมอ และจะวนกลับหลังจาก 2 ⁵²ไมโครวินาที^{[ 66 ]}

ค่า TODC สามารถเข้าถึงได้โดยโปรแกรมในโหมดผู้ใช้ และมักใช้สำหรับการจับเวลาและการสร้างรหัสเฉพาะสำหรับเหตุการณ์ต่างๆ

แม้ว่า IBM จะได้กำหนดและใช้งานรูปแบบฮาร์ดแวร์ที่ยาวกว่า (128 บิต) ในเครื่องรุ่นใหม่ๆ ซึ่งขยายตัวจับเวลาทั้งสองด้านออกไปอย่างน้อย 8 บิต แต่โปรแกรมจำนวนมากยังคงพึ่งพารูปแบบ 64 บิต ซึ่งยังคงเป็นส่วนย่อยที่สามารถเข้าถึงได้ของตัวจับเวลาที่ยาวกว่า

การกำหนดตารางเวลาแผนการบำรุงรักษาในระบบ ERP SAP S/4HANAรองรับเฉพาะวันที่สิ้นสุดจนถึงวันที่ 19 มกราคม 2048 (24,855 วันนับจากวันที่ 1 มกราคม 1980 ซึ่งตรงกับ 2 ³¹วินาทีเมื่อปัดเศษลงเป็นวันเต็ม) ซึ่งเกี่ยวข้องกับเครื่องมือวางแผนการผลิต การบำรุงรักษา และการตรวจสอบ^{[ 67 ]}ปัญหานี้ได้รับการแก้ไขแล้วในการอัปเดตเวอร์ชันใหม่กว่า โดยรองรับวันที่จนถึงปี 9999

การเปลี่ยนหมายเลขสัปดาห์ของระบบ GPS จะเกิดขึ้นเป็นครั้งที่สี่ในเวลา 23:59:41 ของวันที่ 7 กรกฎาคม 2058

ตามข้อกำหนด Single UNIX Specificationสำหรับการแยกวิเคราะห์ปีสองหลักโดยใช้strptime()"ค่าในช่วง [69, 99] จะหมายถึงปี 1969 ถึง 1999 รวมทั้งสิ้น และค่าในช่วง [00, 68] จะหมายถึงปี 2000 ถึง 2068 รวมทั้งสิ้น" ^{[ 5 ] [ 68 ]}หมายความว่า เมื่อแยกวิเคราะห์โดยstrptime()ปีสองหลัก "69" จะถูกตีความว่าเป็นปี 1969 แทนที่จะเป็นปี 2069

โปรแกรมที่จัดเก็บวันที่เป็นจำนวนวันนับจากวันที่กำหนด (หรือยุคเริ่มต้น ) มีความเสี่ยงต่อผลกระทบจากการวนรอบหรือการวนซ้ำ หากค่าไม่กว้างพอที่จะทำให้ค่าวันที่ครอบคลุมช่วงเวลาที่ยาวนานเพียงพอตามที่แอปพลิเคชันคาดหวัง ค่าไบนารี 16 บิตแบบมีเครื่องหมายจะวนรอบหลังจาก 32,768 (2¹⁵ ⁾วันนับจากวันที่ยุคเริ่มต้น ทำให้เกิดค่าลบ ระบบเมนเฟรมบางระบบประสบความล้มเหลวของซอฟต์แวร์เนื่องจากมีการเข้ารหัสวันที่เป็นจำนวนวันนับจากวันที่ 1 มกราคม 1900 ซึ่งทำให้ได้จำนวนวันติดลบที่ไม่คาดคิดในวันที่วนรอบคือวันที่ 18 กันยายน 1989 ในทำนองเดียวกัน การนับวันไบนารี 16 บิตแบบไม่มีเครื่องหมายจะล้นหลังจาก 65,536 (2¹⁶ ⁾วัน ซึ่งจะถูกตัดทอนเป็นค่าศูนย์ สำหรับซอฟต์แวร์ที่ใช้ยุคเริ่มต้นของวันที่ 1 มกราคม 1900 เหตุการณ์นี้จะเกิดขึ้นในวันที่ 6 มิถุนายน 2079 ^{[ 5 ]}

โทรศัพท์ Nokia บางรุ่น (หรืออาจจะทุกรุ่น) ที่ใช้ระบบปฏิบัติการSeries 40 (เช่นNokia X2-00 ) รองรับวันที่ได้ถึงแค่ 31 ธันวาคม 2079 เท่านั้น ดังนั้นจึงไม่สามารถแสดงวันที่หลังจากนั้นได้ วิธีแก้ปัญหาอย่างหนึ่งคือใช้ปี 1996, 2024 หรือ 2052 แทนปี 2080 (ซึ่งเป็นปีอธิกสุรทินที่ใช้งานร่วมกันได้) เพื่อแสดงวันในสัปดาห์ วันที่ และเดือนที่ถูกต้องบนหน้าจอหลัก

ระบบคอมพิวเตอร์ IBM PC และ DOS หลายระบบจัดเก็บปีภายในเป็นค่าสองหลักตั้งแต่ปี 1980 เช่นเดียวกับ RTC หลายตัว และค่าเหล่านี้จะเปลี่ยนไปหลังจากวันที่ 31 ธันวาคม 2079

APIสำหรับกำหนดวันที่ไฟล์และฟังก์ชันการแปลง (เช่นINT 21h /AH=2Ah) ใน DOSและWindowsรองรับวันที่อย่างเป็นทางการถึง 31 ธันวาคม 2099 (แม้ว่าระบบไฟล์ FAT ที่อยู่เบื้องหลัง จะรองรับวันที่ได้ถึง 2107 ตามทฤษฎีก็ตาม) ดังนั้น ระบบปฏิบัติการที่ใช้ DOS รวมถึงแอปพลิเคชันที่แปลงรูปแบบอื่นเป็นรูปแบบ FAT/DOS อาจแสดงพฤติกรรมที่ไม่คาดคิดตั้งแต่วันที่ 1 มกราคม 2100 เป็นต้นไป

ในทำนองเดียวกัน เครื่องเล่นเกม Nintendo DS, GameCube และ Sony PlayStation 4 อนุญาตให้ผู้ใช้ตั้งวันที่ได้ถึงแค่ปี 2099 เท่านั้น ในกรณีของ Nintendo DS ระบบจะไม่เลื่อนเวลาเกินวันที่ 31 ธันวาคม 2099 ในขณะที่ GameCube และ PS4 จะยังคงเลื่อนเวลาต่อไปยังปี 2100 และหลังจากนั้น แม้ว่าผู้ใช้เครื่องเล่นเกมเหล่านั้นจะไม่สามารถป้อนวันที่และเวลาล่วงหน้าได้ไกลขนาดนั้นก็ตาม

ปัญหาอีกประการหนึ่งจะเกิดขึ้นในวันที่ 28 กุมภาพันธ์ ค.ศ. 2100 เนื่องจากปี ค.ศ. 2100 ไม่ใช่ปีอธิกสุรทินเนื่องจากการใช้งานปีอธิกสุรทินทั่วไปหลายๆ วิธีนั้นไม่สมบูรณ์หรือเรียบง่ายเกินไป จึงอาจเข้าใจผิดว่าปี ค.ศ. 2100 เป็นปีอธิกสุรทิน ทำให้วันที่เปลี่ยนจาก 28 กุมภาพันธ์ ค.ศ. 2100 เป็น 29 กุมภาพันธ์ ค.ศ. 2100 แทนที่จะเป็น 1 มีนาคม ค.ศ. 2100

ฮาร์ดแวร์ RTC DS3231 ประสบปัญหาปี 2100 เนื่องจากใช้ตัวเลขสองหลักในการจัดเก็บปี^{[ 69 ]}

รูปแบบไฟล์ โปรโตคอลการสื่อสาร และอินเทอร์เฟซแอปพลิเคชันที่มีอยู่จำนวนมากใช้รูปแบบวันที่ของUnixtime_t ที่แตกต่างกัน โดยจัดเก็บจำนวนวินาทีตั้งแต่ยุค Unix (เที่ยงคืน UTC, 1 มกราคม 1970) เป็น จำนวนเต็มไบนารี 32 บิตที่ ไม่มีเครื่องหมาย ค่านี้จะวนกลับในวันที่ 7 กุมภาพันธ์ 2106 เวลา 06:28:16 UTC นั่นคือ ณ เวลานี้ จำนวนวินาทีตั้งแต่ 1 มกราคม 1970 อยู่FFFFFFFFในรูปแบบเลขฐานสิบหก^{[ 5 ]}

ปัญหาการแสดงผลการจัดเก็บข้อมูลนี้ไม่เกี่ยวข้องกับโปรแกรมที่จัดเก็บและประมวลผลเวลาของระบบภายในโดยใช้ค่าจำนวนเต็ม 64 บิตแบบมีเครื่องหมาย

การประทับเวลาวันที่ที่จัดเก็บไว้ในระบบไฟล์ FATซึ่งเปิดตัวครั้งแรกใน86-DOS 0.42ในปี 1981 และนำมาใช้ต่อในMS-DOS , PC DOS , DR-DOSเป็นต้น จะเต็มเมื่อสิ้นสุดวันที่ 31 ธันวาคม 2107 ^{[ 5 ]}การประทับเวลาวันที่แก้ไขล่าสุด (และใน DELWATCH 2.0+ ยังรวมถึงการประทับเวลาวันที่ลบไฟล์และตั้งแต่DOS 7.0ขึ้นไป อาจรวมถึงการประทับเวลาวันที่เข้าถึงล่าสุดและการประทับเวลาวันที่สร้างด้วย ) จะถูกจัดเก็บไว้ในรายการไดเร็กทอรีโดยแสดงปีเป็นตัวเลขเจ็ดบิตที่ไม่มีเครื่องหมาย (0–127) เทียบกับปี 1980 ดังนั้นจึงไม่สามารถระบุวันที่ใด ๆ ในปี 2108 และหลังจากนั้นได้ ฟังก์ชัน APIที่กำหนดไว้เพื่อดึงข้อมูลวันที่เหล่านี้อย่างเป็นทางการรองรับเฉพาะวันที่ถึง 31 ธันวาคม 2099 เท่านั้น

สิ่งนี้จะส่งผลกระทบต่อไฟล์ ZIP ด้วยเช่นกัน เนื่องจากไฟล์ ZIP ใช้การประทับเวลาการแก้ไขไฟล์แบบ FAT ภายใน

วันที่ในระบบ GPS จะแสดงเป็นหมายเลขสัปดาห์และหมายเลขวันในสัปดาห์ โดยหมายเลขสัปดาห์ในตอนแรกจะใช้ค่า 10 บิตและข้อความนำทาง GPS ที่ทันสมัยจะใช้ฟิลด์ 13 บิต ระบบ 10 บิตจะเปลี่ยนเป็นศูนย์ทุกๆ 1024 สัปดาห์ (ประมาณ 19.6 ปี) หลังจากวันอาทิตย์ที่ 6 มกราคม 1980 ( ยุค GPS ) และระบบ 13 บิตจะเปลี่ยนเป็นศูนย์ทุกๆ 8192 สัปดาห์ ระบบ 13 บิตจะเปลี่ยนเป็นศูนย์ในปี 2137 ^{[ 5 ] [ 11 ] [ 12 ]}

RISC OSจัดเก็บวันที่เป็นเซนติวินาที (หนึ่งในร้อยของวินาที) นับตั้งแต่วันที่ 1 มกราคม ค.ศ. 1900 ในห้าไบต์ (40 บิต) การประทับเวลาเหล่านี้ใช้ภายในและเปิดเผยในเมตาเดตาของไฟล์ (ที่อยู่โหลดและเรียกใช้) ^{[ 70 ]}ค่านี้จะล้นในวันที่ 3 มิถุนายน ค.ศ. 2248 เวลา 06:57:57.75 UTC ^{[ 5 ]}

ระบบจับเวลาความละเอียดสูงบางระบบนับนาโนวินาทีตั้งแต่1 มกราคม 1970โดยใช้จำนวนเต็มแบบมีเครื่องหมาย 64 บิต ซึ่งจะเกิดการโอเวอร์โฟลว์ในวันที่11 เมษายน 2262เวลา 23:47:16 UTC API ของภาษาโปรแกรม GoUnixNanoเป็นตัวอย่างหนึ่ง^{[ 71 ]}ตัวอย่างอื่นๆ ได้แก่ อ็อบเจ็กต์ Timestamp ใน Python pandas [ ^{72 ]}คลาสในC++เมื่อตั้งค่าเป็นความแม่นยำระดับนาโนวินาที^{[ 73 ] และ}ตัวจับเวลาQEMU ^{[ 74 ]}chrono

ระบบที่ใช้สตริงที่มีความยาว 10 ตัวอักษรในการบันทึกเวลา Unixอาจมีปัญหาในการรายงานเวลาที่เกิน 20 พฤศจิกายน 2286 เวลา 17:46:39 UTC ซึ่งเป็นเวลาสิบพันล้านวินาทีหลังจากยุค Unix ^{[ 5 ]}

ในext4ซึ่งเป็นระบบไฟล์เริ่มต้นสำหรับระบบปฏิบัติการ Linux หลายตัว บิตสองบิตล่างสุด{a,c,m}time_extraจะถูกใช้เพื่อขยาย{a,c,m}timeฟิลด์ ทำให้ปัญหาในปี 2038 เลื่อนไปเป็นปี 2446 ^{[ 75 ]} ภายในฟิลด์ 32 บิต "พิเศษ" นี้ บิตสองบิตล่างสุดจะถูกใช้เพื่อขยายฟิลด์วินาทีให้เป็นจำนวนเต็ม 34 บิตแบบมีเครื่องหมาย บิต 30 บิตบนสุดจะถูกใช้เพื่อให้ความแม่นยำของไทม์สแตมป์ระดับนาโนวินาที ดังนั้น ไทม์สแตมป์จะไม่ล้นจนกว่าจะถึงเดือนพฤษภาคม 2446 ^{[ 76 ]}

ในระดับเวลาหลายพันปี ปฏิทินเกรกอเรียนจะล้าหลังฤดูกาลทางดาราศาสตร์ นี่เป็นเพราะความเร็วในการหมุนของโลกค่อยๆ ช้าลงซึ่งทำให้แต่ละวันยาวขึ้นเล็กน้อยเมื่อเวลาผ่านไป (ดูการเร่งตัวของกระแสน้ำและวินาทีอธิกสุรทิน ) ในขณะที่ปีมีระยะเวลาที่สม่ำเสมอกว่า

ในศตวรรษที่ 19 เซอร์จอห์น เฮอร์เชลได้เสนอการปรับเปลี่ยนปฏิทินเกรกอเรียนโดยเพิ่มวันอธิกสุรทิน 969 ​​วันทุกๆ 4000 ปี แทนที่จะเป็น 970 วันตามที่ปฏิทินเกรกอเรียนกำหนดไว้ในช่วงเวลาเดียวกัน^{[ 77 ]}การปรับเปลี่ยนนี้จะลดจำนวนวันเฉลี่ยต่อปีเหลือ 365.24225 วัน ข้อเสนอของเฮอร์เชลจะทำให้ปี 4000 และจำนวนทวีคูณของ 4000 เป็นปีปกติแทนที่จะเป็นปีอธิกสุรทิน แม้ว่าการปรับเปลี่ยนนี้จะถูกเสนอมาหลายครั้งแล้ว แต่ก็ไม่เคยได้รับการนำมาใช้อย่างเป็นทางการ^{[ 78 ]}

ในขณะที่ซอฟต์แวร์ส่วนใหญ่ (รวมถึงExcel , JavaScriptและR ) ในปัจจุบันถือว่าปี 4000 และ 8000 เป็นปีอธิกสุรทิน (เนื่องจากหารด้วย 400 ลงตัว) แต่SASได้นำ "กฎปี 4000" มาใช้ ดังนั้น ด้วยซอฟต์แวร์ปัจจุบัน การแปลงวันที่ระหว่าง SAS และซอฟต์แวร์อื่น ๆ จะไม่ตรงกันหลังจากวันที่ 28 กุมภาพันธ์ ค.ศ. 4000 ^{[ 79 ] [ 80 ]}

Microsoft Outlookใช้วันที่ 1 มกราคม 4501 เป็นตัวแทนสำหรับ "ไม่มี" หรือ "ว่างเปล่า" ^{[ 5 ] [ 81 ] [ 82 ]}

ปี 10,000 จะเป็นปีตามปฏิทินเกรกอเรียนปีแรกที่มีตัวเลขห้าหลัก ระบบที่อนุญาตให้ใช้ตัวเลขปีได้สูงสุดเพียงสี่หลักจะมีปัญหาในการจัดการกับปีในอนาคตทั้งหมดที่เป็นเลขยกกำลังของ 10 รวมถึงวันที่ก่อนสหัสวรรษที่ 10 ก่อนคริสต์ศักราชด้วย

ณ ปี 2026 วันที่สูงสุดที่รองรับสำหรับการคำนวณโดยโปรแกรมสเปรดชีตMicrosoft Excelคือ 31 ธันวาคม 9999 ^{[ 83 ]}

ระบบไฟล์ดิสก์ออปติคอลISO 9660และUDFมีช่วงวันที่สิ้นสุดที่ปี 9999 ^{[ 84 ] [ 85 ]}

UUIDเวอร์ชัน 7 ใช้การประทับเวลา 48 บิต ซึ่งจะเกิดการล้นในปี ค.ศ. 10889 ^{[ 86 ]}

ในภาษาการเขียนโปรแกรม C#หรือภาษาใดๆ ที่ใช้.NETโครงสร้างDateTimeจะเก็บการประทับเวลาสัมบูรณ์เป็นจำนวนไมโครวินาทีหนึ่งในสิบ (10 ⁻⁷  วินาที หรือที่เรียกว่า "ticks" ^{[ 87 ]} ) นับตั้งแต่เที่ยงคืน (00:00:00.0000000 UTC) ของวันที่ 1 มกราคมค.ศ. 1ในปฏิทินเกรกอเรียนแบบย้อนหลัง [ ^{88 ]}ซึ่งจะทำให้จำนวนเต็ม 64 บิตที่มีเครื่องหมายเกิดการล้นในวันที่ 14 กันยายน 29,228 เวลา 02:48:05.4775808 UTC ^{[ 5 ] [ 89 ] โครงสร้าง}การรักษาเวลาในแอปพลิเคชันและบริการต่างๆ ของ Microsoft มีความละเอียด 100 นาโนวินาที เช่นประเภทข้อมูลของPower Automate ^{[ 90 ]}การสืบค้นในAzure Cosmos DB [ ^{91 ] และ}พารามิเตอร์ ใน คำสั่งWindows PowerShellต่างๆ^{[ 92 ]}และสิ่งเหล่านี้ทั้งหมดจะประสบปัญหาที่คล้ายคลึงกัน อย่างไรก็ตาม วันที่หลังจาก 31 ธันวาคม 9999 เวลา 23:59:59.9999999 UTC ถือว่า "ไม่ได้รับการสนับสนุน" และการดำเนินการเกี่ยวกับเวลาจะจงใจแสดงข้อผิดพลาดเมื่อการคำนวณส่งผลให้ได้วันที่หลังจาก 9999 ^{[ 93 ]}TIMEGETCURRENTTICKSTimeSpan

ในระบบปฏิบัติการWindowsFILETIMEโครงสร้างจะเก็บจำนวนไมโครวินาทีในหน่วยสิบตั้งแต่เที่ยงคืน (00:00:00.0000000 UTC) ของวันที่1 มกราคม ค.ศ. 1601ในปฏิทินเกรกอเรียนแบบย้อนหลังเป็นจำนวนเต็ม 64 บิตแบบมีเครื่องหมาย ค่านี้จะเกิดการโอเวอร์โฟลว์ในวันที่ 14 กันยายน ค.ศ. 30,828 เวลา 02:48:05 UTC หลังจากนั้น Windows จะไม่สามารถยอมรับวันที่ได้อีกต่อไปและจะแสดงข้อผิดพลาด "เวลาของระบบไม่ถูกต้อง" ^{[ 5 ] [ 94 ]}

ในทำนองเดียวกันGETCURRENTTICKSSTATICคำสั่งในCosmos DBจะส่งคืนจำนวนรอบ 100 นาโนวินาทีตั้งแต่ยุค Unix เที่ยงคืน (00:00:00.0000000 UTC) ในวันที่ 1 มกราคม พ.ศ. 2513 ^{[ 95 ]}ซึ่งจะวนกลับมาเริ่มต้นใหม่ในวันที่ 14 กันยายน พ.ศ. 2510 เวลา 02:48:05 ^{[ 96 ]}

โปรแกรมที่ประมวลผลปีเป็นค่า 16 บิต อาจพบปัญหาในการจัดการกับปี 32,768 หรือ 65,536 ขึ้นอยู่กับว่าค่าดังกล่าวถูกมองว่าเป็นจำนวนเต็มที่มีเครื่องหมายหรือไม่มีเครื่องหมาย

สำหรับระบบที่ใช้จำนวนเต็ม 16 บิตแบบมีเครื่องหมาย ปีหลังจาก 32,767 อาจถูกตีความว่าเป็นจำนวนลบ^{[ 5 ] [ 97 ]}โดยเริ่มจาก −32,768 ซึ่งอาจแสดงเป็น 32,768 ก่อน  คริสต์ศักราชในระบบที่ใช้จำนวนเต็ม 16 บิตแบบไม่มีเครื่องหมาย ปัญหามีแนวโน้มที่จะปรากฏให้เห็นมากขึ้นโดยที่ปี 65,536 แสดงเป็นปีที่ 0 ^{[ 5 ] [ 98 ]}หรือปี 65,537 วนกลับไปที่ปีที่ 1

คลังเก็บไลบรารีแบบคงที่ที่สร้างโดยarคำสั่ง Unix จะเก็บการประทับเวลาเป็นสตริง ASCII ที่มีตัวเลขทศนิยมของวินาทีหลังจากยุค Unixโดยมีขีดจำกัดที่อักขระ ASCII 12 ตัว ค่านี้จะวนกลับในเวลา 01:46:40 UTC ของวันที่ 27 กันยายน 33,658 ซึ่งเป็นเวลาหนึ่งล้านล้านวินาทีหลังจากยุค Unix ^{[ 5 ]}

ปี 100,000 จะเป็นปีตามปฏิทินเกรกอเรียนปีแรกที่มีตัวเลขหกหลัก

JavaScript 's Date API จัดเก็บวันที่เป็นจำนวนมิลลิวินาทีนับตั้งแต่วันที่ 1 มกราคม พ.ศ. 2513 วันที่จะมีช่วง ±100,000,000 วันจากยุคเริ่มต้น ซึ่งหมายความว่าโปรแกรมที่เขียนด้วย JavaScript โดยใช้ Date API ไม่สามารถจัดเก็บวันที่เกินวันที่ 13 กันยายน พ.ศ. 275,760 ได้^{[ 5 ] [ 99 ]}

ระบบที่จัดเก็บเวลา Unix เป็นวินาทีโดยใช้จำนวนเต็ม 64 บิตแบบมีเครื่องหมายสามารถแสดงวันที่และเวลาได้จนถึง 15:30:08 UTC ของวันอาทิตย์ที่ 4 ธันวาคม ค.ศ. 292,277,026,596 ^{[ 5 ] [ 100 ] [ 101 ]}อย่างไรก็ตาม ปีนี้อยู่ไกลในอนาคต มาก (เกินกว่าอายุขัยที่คาดการณ์ได้ของโลกดวงอาทิตย์และแม้กระทั่งเกินกว่าการคาดการณ์บางอย่างเกี่ยวกับอายุขัยของจักรวาล ) จึงมักถูกอ้างถึงในฐานะเรื่องที่น่าสนใจทางทฤษฎี เรื่องตลก หรือเป็นข้อบ่งชี้ว่าปัญหารุ่นก่อนหน้า เช่น ปัญหาปี 2038 ไม่สามารถ "แก้ไข" ได้อย่างแท้จริงตลอดไป

ใน Microsoft Windows 7, Windows Server 2003, Windows Server 2008 และ Windows Vista ข้อมูลการเริ่มต้นการเชื่อมต่อ TCP จะถูกจัดเก็บในหน่วยร้อยส่วนของวินาที โดยใช้จำนวนเต็ม 32 บิตที่ไม่มีเครื่องหมาย ซึ่งทำให้การเชื่อมต่อ TCP ล้มเหลวหลังจาก 497 วัน^{[ 102 ]}

Windows 95 และ Windows 98 มีปัญหาเกี่ยวกับการหมุนเวียนในไดรเวอร์อุปกรณ์เสมือนVTDAPI.VXDซึ่งใช้จำนวนเต็ม 32 บิตที่ไม่มีเครื่องหมายเพื่อวัดเวลาการทำงานของระบบเป็นมิลลิวินาที ค่านี้จะล้นหลังจาก 49.7 วัน ทำให้ระบบหยุดทำงาน^{[ 103 ]}

จนถึงเวอร์ชัน 6.0 แพลตฟอร์ม .NET ของ Microsoft มีบั๊กที่ทำให้การไต่ระดับเธรดพูลล้มเหลวเป็นระยะหลังจาก 49.7 วันเนื่องจากเกิดการล้นขณะจัดการมิลลิวินาทีตั้งแต่เริ่มต้น^{[ 104 ]}

เครื่องบิน โบอิ้ง 787มีปัญหาซอฟต์แวร์ที่เกี่ยวข้องกับการจัดเก็บเวลาอย่างน้อยสองครั้ง ในปี 2558 มีรายงานข้อผิดพลาดที่ระบบจัดเก็บเวลาทำงานเป็นหน่วยร้อยส่วนของวินาที โดยใช้จำนวนเต็ม 32 บิตแบบมีเครื่องหมาย ค่านี้จะล้นหลังจาก 248 วัน หลังจากนั้นระบบควบคุมเครื่องกำเนิดไฟฟ้าบนเครื่องบินจะขัดข้อง ทำให้เครื่องบินสูญเสียพลังงาน^{[ 105 ] [ 106 ]}

ในปี 2020 สำนักงานบริหารการบินแห่งสหรัฐอเมริกาได้ออกคำสั่งด้านความปลอดภัยทางการบินที่กำหนดให้ผู้ประกอบการเครื่องบิน 787 ต้องปิดระบบการทำงานของเครื่องบินให้สมบูรณ์ก่อนที่จะใช้งานครบ 51 วัน มิฉะนั้นระบบจะเริ่มแสดงข้อมูลที่ทำให้เข้าใจผิด^{[ 107 ]}

แพลตฟอร์มArduinoให้เวลาสัมพัทธ์ผ่านmillis()ฟังก์ชัน ฟังก์ชันนี้จะส่งคืนจำนวนเต็ม 32 บิตที่ไม่มีเครื่องหมาย ซึ่งแสดงถึง "มิลลิวินาทีตั้งแต่เริ่มต้น" และจะวนกลับทุกๆ 49 วัน โดยค่าเริ่มต้น นี่เป็นแหล่งเวลาเดียวที่มีอยู่ในแพลตฟอร์ม และโปรแกรมต้องระมัดระวังเป็นพิเศษในการจัดการกับการวนกลับ^{[ 108 ]}ภายใน ฟังก์ชัน millis()นี้ใช้การนับการขัดจังหวะของตัวจับเวลา โหมดประหยัดพลังงานบางโหมดจะปิดใช้งานการขัดจังหวะ ดังนั้นจึงหยุดไม่ให้ตัวนับเดินหน้าในระหว่างการนอนหลับ^{[ 109 ]}

นอกจากนี้ สำหรับปีประวัติศาสตร์ อาจมีปัญหาในการจัดการเหตุการณ์ทางประวัติศาสตร์ ตัวอย่างเช่น:

• ปัญหาปีที่ 0
• ปัญหาปี 1000
• ปัญหาปี ค.ศ. 1414
• ปัญหาปี ค.ศ. 1582
• ปัญหาปี ค.ศ. 1900

• ไฮเซนบั๊ก  – ข้อผิดพลาดของซอฟต์แวร์ที่ดูเหมือนจะเปลี่ยนแปลงไปเมื่อทำการดีบั๊ก
• มูลนิธิลองนาว  – องค์กรไม่แสวงหาผลกำไรของอเมริกา