ปัญหา ปี2038 (หรือที่รู้จักกันในชื่อ^{Y2038 [} 1 ] ^{Y2K38 ซู}เปอร์บั๊กY2K38หรือเอโพคาลิปส์^{[ 2 ] [ 3 ]} ) เป็นปัญหาการคำนวณเวลาที่ทำให้ระบบคอมพิวเตอร์บางระบบไม่สามารถแสดงเวลาหลังจาก 03:14:07 UTCของวันที่ 19 มกราคม 2038 ได้

ปัญหาดังกล่าวเกิดขึ้นในระบบที่วัดเวลาแบบ Unix —จำนวนวินาทีที่ผ่านไปนับตั้งแต่ Unix epoch (00:00:00 UTC ในวันที่ 1 มกราคม 1970)—และเก็บไว้ในจำนวนเต็ม 32 บิตแบบมีเครื่องหมายเมื่อ ค่าสูงสุดของ ชนิดข้อมูลถูกเกินไป จำนวนเต็มจะเกิดการโอเวอร์โฟลว์ไปยังค่าต่ำสุด ซึ่งระบบจะตีความว่าเป็นอดีต ปัญหานี้คล้ายกับปัญหาปี 2000แต่เกิดจากข้อจำกัดใน การแสดงเวลา แบบฐาน 2 (ไบนารี) แทนที่จะเป็นฐาน 10

ระบบคอมพิวเตอร์ที่ใช้เวลาสำหรับการคำนวณที่สำคัญอาจพบข้อผิดพลาดร้ายแรงหากไม่แก้ไขปัญหาปี 2038 แอปพลิเคชันบางตัวที่ใช้ข้อมูลวันที่ในอนาคตได้พบข้อบกพร่องนี้แล้ว^{[ 4 ] [ 5 ]}ระบบที่มีความเสี่ยงมากที่สุดคือระบบที่อัปเดตไม่บ่อยหรือไม่เคยอัปเดตเลย เช่น ระบบ เก่าและระบบฝังตัวระบบสมัยใหม่และการอัปเดตซอฟต์แวร์แก้ไขปัญหานี้โดยใช้ จำนวนเต็ม 64 บิต แบบมีเครื่องหมาย ซึ่งจะใช้ เวลา292 พันล้านปีในการโอเวอร์โฟลว์ ซึ่งประมาณ 21 เท่าของอายุโดยประมาณของจักรวาล^{[ 6 ]}

ระบบคอมพิวเตอร์หลายระบบใช้เวลาแบบ Unixซึ่งเป็นมาตรฐานสากลสำหรับการรักษาเวลาแบบดิจิทัล ในการวัดเวลาและวันที่ เวลาแบบ Unix ถูกกำหนดให้เป็นจำนวนวินาทีที่ผ่านไป โดยไม่นับวินาทีอธิกสุรทินนับตั้งแต่เวลา 00:00:00 UTC ของวันที่ 1 มกราคม 1970 ซึ่งเรียกว่ายุค Unix

เวลาในระบบ Unix นั้นโดยทั่วไปจะถูกเข้ารหัสเป็นจำนวนเต็ม 32 บิตแบบมีเครื่องหมาย ซึ่งเป็นชนิดข้อมูลที่ประกอบด้วยเลขฐานสอง 32 หลัก (บิต) ที่แสดงค่าจำนวนเต็ม โดยคำว่า 'มีเครื่องหมาย' หมายความว่าตัวเลขนั้นสามารถแสดงได้ทั้งจำนวนบวก จำนวนลบ และศูนย์ และโดยปกติจะจัดเก็บในรูปแบบส่วนเติมเต็มสอง^{[ a ]}ดังนั้น จำนวนเต็ม 32 บิตแบบมีเครื่องหมายจึงสามารถแสดงค่าจำนวนเต็มได้ตั้งแต่ −(2³¹ ⁾ถึง^2³¹  − 1 รวมทั้งสองค่าด้วย ดังนั้น หากใช้จำนวนเต็ม 32 บิตแบบมีเครื่องหมายเพื่อจัดเก็บเวลา Unix เวลาล่าสุดที่สามารถจัดเก็บได้คือ 2 ³¹  − 1 ( 2,147,483,647 ) ^{[ b ]}วินาทีหลังจากยุคเริ่มต้น ซึ่งคือ 03:14:07 UTC ในวันที่ 19 มกราคม 2038 ^{[ 7 ]}ระบบที่พยายามเพิ่มค่านี้ขึ้นอีกหนึ่งวินาทีเป็น 2 ³¹วินาทีหลังจากยุคเริ่มต้น (03:14:08) จะประสบปัญหาจำนวนเต็มล้นโดยไม่ได้ตั้งใจจะเปลี่ยนบิตเครื่องหมายเพื่อระบุจำนวนลบ ซึ่งจะเปลี่ยนค่าจำนวนเต็มเป็น −(2 ³¹ ) หรือ 2 ³¹วินาทีก่อนยุคเริ่มต้น แทนที่จะเป็นหลังจาก ยุคเริ่มต้น ซึ่งระบบจะตีความว่าเป็น 20:45:52 UTC ในวันที่ 13 ธันวาคม 1901 จากตรงนี้ ระบบจะนับขึ้นไปเรื่อยๆ จนถึงศูนย์ แล้วจึงนับขึ้นไปจนถึงจำนวนเต็มบวกอีกครั้ง เนื่องจากระบบคอมพิวเตอร์จำนวนมากใช้การคำนวณเวลาในการเรียกใช้ฟังก์ชันที่สำคัญ ข้อผิดพลาดนี้อาจก่อให้เกิดปัญหาที่ร้ายแรงได้

ระบบใดๆ ที่ใช้โครงสร้างข้อมูลที่มีการแสดงเวลาแบบ 32 บิตที่มีเครื่องหมาย มีความเสี่ยงที่จะล้มเหลวโดยธรรมชาติ การรวบรวมรายชื่อโครงสร้างข้อมูลเหล่านี้ทั้งหมดแทบเป็นไปไม่ได้ แต่มีโครงสร้างข้อมูลที่รู้จักกันดีซึ่งมีปัญหาเรื่องเวลาแบบ Unix อยู่หลายอย่าง:

• ระบบไฟล์ที่ใช้ 32 บิตในการแสดงเวลาในinodeเช่นext2 , ext3และreiserFS
• ฐานข้อมูลที่มีฟิลด์เวลาแบบ 32 บิต
• ภาษาสำหรับการสืบค้นฐานข้อมูล (เช่นSQL ) ที่มีUNIX_TIMESTAMP()คำสั่งคล้าย -like
• อุปกรณ์ Android 32 บิตจำนวนมากบน Android 4 หรือรุ่นก่อนหน้า รวมถึงZTE Blade [ ^{8 ] Google} Nexus 7 ^{[ 9 ]}และแท็บเล็ตAndroid ของ Toshiba ปี 2012 ^{[ 10 ]}
• Mac PowerPCในยุคOS Xจะมีนาฬิการะบบค้างอยู่ที่เวลาเปลี่ยนรอบตั้งแต่Mac OS X Tigerเป็นต้น ไป ^{[ 11 ]}
• อุปกรณ์ iOS 32 บิตตั้งแต่iPhone 5ขึ้นไปที่ใช้iOS 9จะไม่สามารถปลดล็อกหรือเข้าสู่โหมดชาร์จได้อย่างต่อเนื่อง และนาฬิกาบนหน้าจอล็อกจะไม่แสดงขึ้น^{[ 12 ]}
• ตั้งแต่Windows 10เวอร์ชัน22H2 เป็นต้น ไป หาก อุปกรณ์ x86 (32 บิต) ไม่ได้เปิดใช้งาน ณ จุดเปลี่ยนรอบ แต่เริ่มต้นใช้งานหลังจากเปลี่ยนรอบแล้ว นาฬิการะบบสามารถข้ามไปเป็นวันที่ 12 เมษายน พ.ศ. 2160 และตัวเลือกวันที่ในเมนูการตั้งค่าหลักของ Windows 10 จะไม่แสดงตัวเลขที่เลือกได้^{[ 13 ]}
• ซอฟต์แวร์ที่สร้างด้วยVisual Studioมี_gmtime32รูปแบบ (ซึ่งทำหน้าที่เป็นการแมปtime_tเวอร์ชัน 32 บิตของ) หมุนเวียนในวันที่ 19 มกราคม 2038 เวลา 00:00:00 ซอฟต์แวร์ที่สร้างด้วย Visual Studio เวอร์ชันก่อนปี 2005 เป็นที่ทราบกันว่า_gmtimeสอดคล้องกับ_gmtime32และสามารถบังคับให้สอดคล้องกันได้เมื่อสร้างด้วย Visual Studio เวอร์ชัน 32 บิตไปจนถึง Visual Studio 2019 โดยการ_USE_32BIT_TIME_Tระบุ^{[ 14 ]}

ระบบฝังตัวที่ใช้ข้อมูลวันที่สำหรับการคำนวณหรือการบันทึกข้อมูลการวินิจฉัยมีแนวโน้มที่จะได้รับผลกระทบจากปัญหา Y2038 มากที่สุด^{[ 1 ]}แม้ว่าเทคโนโลยีระบบคอมพิวเตอร์จะมีการอัปเดตทุกๆ 18-24 เดือนแต่ระบบฝังตัวได้รับการออกแบบให้มีอายุการใช้งานเท่ากับอายุของเครื่องที่ระบบเหล่านั้นเป็นส่วนประกอบ เป็นไปได้ว่าระบบเหล่านี้บางส่วนอาจยังคงใช้งานอยู่ในปี 2038 การอัปเกรดซอฟต์แวร์ที่ทำงานบนระบบเหล่านี้อาจทำได้ยาก หรือในบางกรณีอาจเป็นไปไม่ได้ ซึ่งในที่สุดอาจต้องเปลี่ยนใหม่หากต้องการแก้ไขข้อจำกัด 32 บิต

ระบบขนส่งหลายระบบ ตั้งแต่เครื่องบินไปจนถึงรถยนต์ ใช้ระบบฝังตัวอย่างกว้างขวาง ในระบบยานยนต์ อาจรวมถึงระบบเบรกป้องกันล้อล็อก (ABS), ระบบควบคุมเสถียรภาพอิเล็กทรอนิกส์ (ESC/ESP), ระบบควบคุมการยึดเกาะถนน (TCS) และระบบขับเคลื่อนสี่ล้อ อัตโนมัติ เครื่องบินอาจใช้ระบบนำทางเฉื่อยและ ตัวรับ สัญญาณGPS ^{[ c ]}

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

อย่างไรก็ตาม นี่ไม่ได้หมายความว่าระบบฝังตัวทั้งหมดจะประสบปัญหา Y2038 เนื่องจากระบบดังกล่าวจำนวนมากไม่จำเป็นต้องเข้าถึงวันที่ สำหรับระบบที่ต้องการเข้าถึงวันที่ ระบบที่ติดตามเฉพาะความแตกต่างระหว่างเวลา/วันที่และไม่ใช่เวลา/วันที่ที่แน่นอน จะไม่ประสบปัญหาใหญ่เนื่องจากลักษณะของการคำนวณ นี่คือปัญหาสำหรับการวินิจฉัยยานยนต์ตามมาตรฐานที่กำหนดโดยกฎหมาย เช่น CARB ( California Air Resources Board ) ^{[ 15 ]}

ในเดือนพฤษภาคม พ.ศ. 2549 มีรายงานเกี่ยวกับปัญหา Y2038 ที่เกิดขึ้นในช่วงแรกใน ซอฟต์แวร์ AOLserverซอฟต์แวร์นี้ได้รับการออกแบบโดยใช้วิธีแก้ ปัญหาเฉพาะหน้า เพื่อจัดการกับคำขอฐานข้อมูลที่ไม่ควรหมดเวลา แทนที่จะจัดการกับกรณีพิเศษนี้โดยเฉพาะ การออกแบบเริ่มต้นกลับกำหนด วัน ที่หมดเวลาโดยพลการในอนาคต โดยค่าเริ่มต้นจะระบุว่าคำขอควรหมดเวลาหลังจากสูงสุดหนึ่งพันล้านวินาที อย่างไรก็ตาม หนึ่งพันล้านวินาทีก่อนวันที่กำหนดในปี พ.ศ. 2549 คือ 01:27:28 UTC ในวันที่ 13 พฤษภาคม พ.ศ. 2549 ดังนั้นคำขอที่ส่งหลังจากเวลานี้จะส่งผลให้วันที่หมดเวลาเกินกว่าวันที่กำหนด ทำให้การคำนวณการหมดเวลาเกิดการล้นและส่งคืนวันที่ที่อยู่ในอดีต ส่งผลให้ซอฟต์แวร์ล่ม เมื่อพบปัญหานี้ ผู้ดูแลระบบ AOLServerต้องแก้ไขไฟล์การกำหนดค่าและตั้งค่าการหมดเวลาเป็นค่าที่ต่ำกว่า^{[ 4 ] [ 5 ]}

ใบรับรอง CAที่ลงนามด้วยตนเองหลายประเภทที่สร้างขึ้นบนระบบ 32 บิตอาจมีวันหมดอายุที่ยาวนานเกินกว่าจุดเปลี่ยนผ่าน ซึ่งจะทำให้ใช้งานไม่ได้อย่างถูกต้อง ส่งผลกระทบต่อ การตรวจสอบ HTTPSบนบริการ (เช่นVPN ) และเว็บไซต์ที่ใช้^{[ 16 ]}

ฟังก์ชันป้องกันมัลแวร์ MS Filtering Engine Update ของ การติดตั้ง Microsoft Exchange Serverเสียหายเมื่อวันที่ 1 มกราคม 2022 หลังจากการอัปเดต ฟังก์ชันดังกล่าวแมปหมายเลข UpdateVersion ที่ประมวลผลแล้ว (ซึ่งใช้รูปแบบ YY-MM-DD-n 9 หรือ 10 หลัก) กับหมายเลขประทับเวลา Unix แม้ว่าเวลาจะแตกต่างกันมาก ดังนั้นเมื่อเอ็นจิ้นได้รับการอัปเดต 220101001 (22-01-01 v001) ซึ่งเอ็นจิ้นเข้าใจว่าหมายถึง 2201010001 ที่มีศูนย์เพิ่มอีกหนึ่งตัวใกล้ๆ ส่วนท้าย เอ็นจิ้นจึงพยายามแมปกับหมายเลขเวลา Unix 32 บิตและล้มเหลวเนื่องจากมีค่าสูงกว่า 2147483647 ^{[ 17 ]}เซิร์ฟเวอร์ Exchange ที่ได้รับผลกระทบไม่สามารถทำงานได้เว้นแต่จะปิดใช้งานฟังก์ชันป้องกันมัลแวร์ และมีการเผยแพร่การแก้ไขอัตโนมัติเมื่อวันที่ 5 มกราคม 2022

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

ไม่มีวิธีแก้ปัญหาสากลสำหรับปัญหาปี 2038 ตัวอย่างเช่น ในภาษา Cการเปลี่ยนแปลงใดๆ ต่อคำจำกัดความของtime_tชนิดข้อมูลจะส่งผลให้เกิด ปัญหา ความเข้ากันได้ของโค้ดในแอปพลิเคชันใดๆ ที่การแสดงวันที่และเวลาขึ้นอยู่กับลักษณะของtime_tจำนวนเต็ม 32 บิตแบบมีเครื่องหมาย การเปลี่ยนtime_tเป็นจำนวนเต็ม 32 บิตแบบไม่มีเครื่องหมาย ซึ่งจะขยายช่วงไปถึงปี 2106 ^{[ 19 ]} (โดยเฉพาะ 06:28:15 UTC ในวันอาทิตย์ที่ 7 กุมภาพันธ์ 2106) จะส่งผลเสียต่อโปรแกรมที่จัดเก็บ ดึงข้อมูล หรือจัดการวันที่ก่อนปี 1970 เนื่องจากวันที่ดังกล่าวแสดงด้วยตัวเลขติดลบ การเพิ่มขนาดของชนิดข้อมูลtime_tเป็น 64 บิตในระบบที่มีอยู่จะทำให้เกิดการเปลี่ยนแปลงที่ไม่เข้ากันกับเค้าโครงของโครงสร้างและอินเทอร์เฟซไบนารีของฟังก์ชัน

ระบบปฏิบัติการส่วนใหญ่ที่ออกแบบมาเพื่อทำงานบน ฮาร์ดแวร์ 64 บิตนั้นใช้จำนวนเต็ม 64 บิตแบบมีเครื่องหมายอยู่แล้วtime_tการใช้ค่า 64 บิตแบบมีเครื่องหมายจะทำให้เกิดวันที่วนรอบใหม่ที่มากกว่าอายุโดยประมาณของจักรวาล ถึงยี่สิบเท่า ซึ่งก็คือประมาณ 292 พันล้านปีนับจากนี้^{[ 20 ]}อย่างไรก็ตาม ซอฟต์แวร์บนระบบปฏิบัติการ 64 บิตยังคงสามารถก่อให้เกิดปัญหาได้โดยการใช้จำนวนเต็ม 32 บิตในการจัดการกับค่าเวลา^{[ 21 ]}ความสามารถในการคำนวณวันที่นั้นถูกจำกัดโดยข้อเท็จจริงที่ว่าtm_yearใช้ค่าจำนวนเต็ม 32 บิตแบบมีเครื่องหมายเริ่มต้นที่ปี 1900 ซึ่งจำกัดปีไว้ที่สูงสุด 2,147,485,547 (2,147,483,647 + 1900) ^{[ 22 ]}

มีการเสนอทางเลือกอื่น (ซึ่งบางส่วนได้นำมาใช้แล้ว) เช่น การจัดเก็บมิลลิวินาทีหรือไมโครวินาทีตั้งแต่ยุคเริ่มต้น (โดยทั่วไปคือ 1 มกราคม 1970 หรือ 1 มกราคม 2000) ในจำนวนเต็ม 64 บิตแบบมีเครื่องหมาย ซึ่งให้ช่วงเวลาขั้นต่ำ 292,000 ปีที่ความละเอียดระดับไมโครวินาที^{[ 23 ] [ 24 ]}โดยเฉพาะอย่างยิ่ง การใช้จำนวนเต็ม 64 บิตแบบมีเครื่องหมายของ Java และ JavaScript เพื่อแสดงการประทับเวลาสัมบูรณ์เป็น "มิลลิวินาทีตั้งแต่ 1 มกราคม 1970" จะทำงานได้อย่างถูกต้องในอีก292 ล้านปี ข้างหน้า ข้อเสนออื่นๆ สำหรับการแสดงเวลาแบบใหม่ให้ความแม่นยำ ช่วง และขนาดที่แตกต่างกัน (เกือบทุกครั้งจะกว้างกว่า 32 บิต) รวมถึงการแก้ปัญหาอื่นๆ ที่เกี่ยวข้อง เช่น การจัดการวินาทีอธิกสุรทินโดยเฉพาะอย่างยิ่ง TAI64 ^{[ 25 ]}เป็นการนำ มาตรฐาน เวลาอะตอมสากล (TAI) มาใช้ ซึ่งเป็นมาตรฐานเวลาจริงสากลในปัจจุบันสำหรับการกำหนดวินาทีและกรอบอ้างอิง

• ตั้งแต่Rubyเวอร์ชัน 1.9.2 (เผยแพร่เมื่อวันที่ 18 สิงหาคม 2010) บั๊กเกี่ยวกับปี 2038 ได้รับการแก้ไขแล้ว^{[ 26 ]}โดยการจัดเก็บเวลาในจำนวนเต็ม 64 บิตแบบมีเครื่องหมายบนระบบที่มี 32 time_tบิต^{[ 27 ]}
• ตั้งแต่NetBSDเวอร์ชัน 6.0 (วางจำหน่ายในเดือนตุลาคม 2012) ระบบปฏิบัติการ NetBSD ใช้สถาปัตยกรรม 64 บิตtime_tสำหรับทั้งสถาปัตยกรรม 32 บิตและ 64 บิต แอปพลิเคชันที่คอมไพล์สำหรับ NetBSD เวอร์ชันเก่าที่มีสถาปัตยกรรม 32 บิตtime_tได้รับการสนับสนุนผ่านเลเยอร์ความเข้ากันได้ของไบนารี แต่แอปพลิเคชันเก่าเหล่านั้นจะยังคงประสบปัญหา Y2038 อยู่^{[ 28 ]}
• OpenBSDตั้งแต่เวอร์ชัน 5.5 ซึ่งวางจำหน่ายในเดือนพฤษภาคม 2014 ยังใช้สถาปัตยกรรม 64 บิตtime_tสำหรับทั้งสถาปัตยกรรม 32 บิตและ 64 บิต ซึ่งแตกต่างจากNetBSD ตรง ที่ไม่มีเลเยอร์ความเข้ากันได้ของไบนารี ดังนั้นแอปพลิเคชันที่คาดหวัง 32 บิตtime_tและแอปพลิเคชันที่ใช้สิ่งอื่นใดที่แตกต่างออกไปtime_tเพื่อจัดเก็บค่าเวลาอาจทำงานผิดพลาด^{[ 29 ]}
• เดิมที Linuxใช้สถาปัตยกรรม 64 บิต สำหรับสถาปัตยกรรม 64 บิตเท่านั้น โดย ABItime_t 32 บิตบริสุทธิ์จะไม่ถูกเปลี่ยนแปลงเนื่องจากความเข้ากันได้แบบย้อนหลัง^{[ 30 ]}ตั้งแต่เวอร์ชัน5.6ในปี 2020 เป็นต้นไป รองรับสถาปัตยกรรม 32 บิตด้วย 64 บิต ซึ่งทำขึ้นเพื่อประโยชน์ของระบบLinux แบบฝังตัว เป็นหลัก ^{[ 31 ]}time_t
• ไลบรารี GNU Cตั้งแต่เวอร์ชัน 2.34 (เผยแพร่เมื่อเดือนสิงหาคม 2021) ได้เพิ่มการสนับสนุนการใช้งาน 64 บิตtime_tบนแพลตฟอร์ม 32 บิตด้วยเวอร์ชัน Linux ที่เหมาะสม การสนับสนุนนี้สามารถเปิดใช้งานได้โดยการกำหนดมาโครพรีโปรเซสเซอร์_TIME_BITSเมื่อ64คอมไพล์ซอร์สโค้ด^{[ 32 ]}
• FreeBSDใช้ 64 บิตtime_tสำหรับสถาปัตยกรรม 32 บิตและ 64 บิตทั้งหมด ยกเว้น i386 32 บิต ซึ่งใช้ 32 บิตแบบมีเครื่องหมายtime_tแทน^{[ 33 ]}
• x32 ABIสำหรับ Linux (ซึ่งกำหนดสภาพแวดล้อมสำหรับโปรแกรมที่มีที่อยู่ 32 บิต แต่รันโปรเซสเซอร์ในโหมด 64 บิต) ใช้ 64 บิตtime_tเนื่องจากเป็นสภาพแวดล้อมใหม่ จึงไม่จำเป็นต้องมีข้อควรระวังเรื่องความเข้ากันได้เป็นพิเศษ^{[ 30 ]}
• ระบบไฟล์เครือข่ายเวอร์ชัน 4 ได้กำหนดฟิลด์เวลาไว้struct nfstime4 {int64_t seconds; uint32_t nseconds;}ตั้งแต่เดือนธันวาคม พ.ศ. 2543 ^{[ 34 ]}เวอร์ชัน 3 รองรับค่า 32 บิตที่ไม่มีเครื่องหมายstruct nfstime3 {uint32 seconds; uint32 nseconds;};[ ^{35 ] ค่า}ที่มากกว่าศูนย์สำหรับฟิลด์วินาทีแสดงถึงวันที่หลังจากเวลา 0 นาฬิกา คือวันที่ 1 มกราคม พ.ศ. 2513 ค่าที่น้อยกว่าศูนย์สำหรับฟิลด์วินาทีแสดงถึงวันที่ก่อนเวลา 0 นาฬิกา คือวันที่ 1 มกราคม พ.ศ. 2513 ในทั้งสองกรณี ฟิลด์ nวินาที (นาโนวินาที) จะต้องถูกเพิ่มเข้าไปในฟิลด์วินาทีสำหรับการแสดงเวลาขั้นสุดท้าย
• ระบบ ไฟล์ ext4เมื่อใช้กับขนาด inode ที่ใหญ่กว่า 128 ไบต์ จะมีฟิลด์ 32 บิตเพิ่มเติมต่อการประทับเวลา ซึ่ง 30 บิตจะใช้สำหรับส่วนนาโนวินาทีของการประทับเวลา และอีก 2 บิตจะใช้เพื่อขยายช่วงการประทับเวลาไปจนถึงปี 2446 ^{[ 36 ]}
• ระบบ ไฟล์ XFSตั้งแต่ Linux 5.10 เป็นต้นไป มีคุณสมบัติ "การประทับเวลาขนาดใหญ่" ที่เป็นตัวเลือก ซึ่งขยายช่วงเวลาการประทับเวลาไปจนถึงปี 2486 ^{[ 37 ]}
• แม้ว่า API ดั้งเดิมของOpenVMSจะรองรับการประทับเวลาได้ถึง 31 กรกฎาคม 31086 ^{[ 38 ]}แต่ไลบรารีรันไทม์ C (CRTL) ใช้จำนวนเต็ม 32 บิตสำหรับtime_t[ ^{39 ] ซึ่ง}เป็นส่วนหนึ่งของงานการปฏิบัติตามมาตรฐาน Y2K ที่ดำเนินการในปี 1998 CRTL ได้รับการแก้ไขให้ใช้จำนวนเต็ม 32 บิตที่ไม่มีเครื่องหมายเพื่อแสดงเวลา โดยขยายช่วงเวลาtime_tไปจนถึง 7 กุมภาพันธ์ 2106 ^{[ 40 ]}
• ตั้งแต่MySQLเวอร์ชัน 8.0.28 ซึ่งวางจำหน่ายในเดือนมกราคม 2022 ฟังก์ชันFROM_UNIXTIME(), UNIX_TIMESTAMP(), และCONVERT_TZ()จะจัดการค่า 64 บิตบนแพลตฟอร์มที่รองรับ ซึ่งรวมถึง Linux, macOS และ Windows เวอร์ชัน 64 บิต^{[ 41 ] [ 42 ]}ในเวอร์ชันเก่ากว่า ฟังก์ชันในตัวเช่นUNIX_TIMESTAMP()จะส่งคืนค่า 0 หลังจากเวลา 03:14:07 UTCในวันที่ 19 มกราคม 2038 ^{[ 43 ]}
• ตั้งแต่MariaDB 11.5.1 ซึ่งวางจำหน่ายในเดือนพฤษภาคม 2024 ประเภทข้อมูลTIMESTAMPและฟังก์ชันFROM_UNIXTIME(), UNIX_TIMESTAMP(), และCONVERT_TZ()จัดการค่า 32 บิตที่ไม่มีเครื่องหมายบน Linux, macOS และ Windows เวอร์ชัน 64 บิต^{[ 44 ]}ซึ่งขยายช่วงเวลาเป็น 2106-02-07 06:28:15 และอนุญาตให้ผู้ใช้จัดเก็บค่าการประทับเวลาดังกล่าวในตารางโดยไม่ต้องเปลี่ยนเค้าโครงการจัดเก็บ จึงยังคงเข้ากันได้กับข้อมูลผู้ใช้ที่มีอยู่
• ตั้งแต่Visual C++ 2005 เป็นต้นไป CRT จะใช้ 64 บิตtime_tเว้นแต่_USE_32BIT_TIME_Tจะมีการกำหนดมาโครพรีโปรเซสเซอร์^{[ 45 ]}อย่างไรก็ตามAPI ของ Windowsเองจะไม่ได้รับผลกระทบจากบั๊กปี 2038 เนื่องจากWindowsติดตามเวลาภายในเป็นจำนวนช่วงเวลา 100 นาโนวินาที นับตั้งแต่วันที่ 1 มกราคม 1601 ในจำนวนเต็มแบบมีเครื่องหมาย 64 บิต ซึ่งจะไม่เกิดการล้นจนกว่าจะถึง^ปี 30,828 [ ^{46 ]}
• ปัญหาบั๊กที่ทำให้เวลาของระบบค้างขณะทำการโรลโอเวอร์ใน OS X ได้รับการแก้ไขแล้วในMac OS X El Capitan
• DOSBox-X ได้ลบการพึ่งพามาโคร Int32x32To64 สำหรับการคำนวณเวลาในเวอร์ชัน 2025.02.01 ^{[ 47 ]}
• สำหรับอุปกรณ์ Windows ที่นาฬิกาถูกปรับให้เร็วขึ้น มีเครื่องมือซอฟต์แวร์หลายตัวที่สามารถแก้ไขการตั้งค่าระบบหรือซิงโครไนซ์กับเซิร์ฟเวอร์เวลาเพื่อบรรเทาผลกระทบได้
• คู่มือไวยากรณ์ของ Microsoft สำหรับ Visual Studio ไม่สนับสนุนการใช้_USE_32BIT_TIME_Tและไม่อนุญาตให้ใช้เมื่อสร้างด้วย Visual Studio เวอร์ชัน 64 บิต^{[ 14 ]}
• แม้ว่า Oracle Access Manager เวอร์ชันที่เป็นปัญหาจะมีอายุมากแล้ว (18 มิถุนายน 2552) แต่ Oracle ก็ได้ออกแพทช์ 33983548 เมื่อวันที่ 6 เมษายน 2565 เวอร์ชันใหม่กว่าของ Oracle Access Manager ยังไม่พบว่าได้รับผลกระทบจากปัญหานี้

• ข้อผิดพลาดเกี่ยวกับการจัดรูปแบบเวลาและการจัดเก็บข้อมูลแสดงรายการปัญหาอื่นๆ ที่คล้ายคลึงกัน ซึ่งมักเกิดจากการเปลี่ยนปีคล้ายกับสาเหตุของปัญหาในปี 2038 นี้
• โดยบังเอิญแล้ว การเปลี่ยนหมายเลขสัปดาห์ของระบบ GPSจะเกิดขึ้นในช่วงปลายปี 2038 แต่ด้วยเหตุผลที่แตกต่างออกไป
• ปัญหาการเปลี่ยนแปลงเวลาในโปรโตคอลเวลาเครือข่ายเวอร์ชัน 3 และเวอร์ชันก่อนหน้าในปี 2036 นั้นคล้ายคลึงกับปัญหาในปี 2038 มาก แต่ก็ไม่เหมือนกันเสียทีเดียว

• Y2038 Proofness Design glibc Wiki
• บทความในหัวข้อ วิธีการทำงานของสิ่งต่างๆ
• คำถามที่พบบ่อยเกี่ยวกับโครงการ Project 2038
• วันที่สำคัญและมีความหมาย 2038 เก็บถาวรเมื่อวันที่ 7 พฤศจิกายน 2020 ที่ Wayback Machine
• ไฟล์ทดแทนที่ปลอดภัยสำหรับ time.h ในปี 2038 บนระบบ 32 บิต
• "การแก้ปัญหาปี 2038 ในเคอร์เนลลินุกซ์ "
• บารานิอุค, คริส (5 พฤษภาคม 2015). "ความผิดพลาดทางตัวเลขที่อาจนำไปสู่หายนะ" . บีบีซี ฟิวเจอร์ .
• Clewett, James. "2,147,483,647 – จุดจบของเวลา [Unix]" . Numberphile . Brady Haran . เก็บถาวรจากต้นฉบับเมื่อ 22 พฤษภาคม 2017 . สืบค้นเมื่อ7 เมษายน 2013 .