นาฬิกา Linux จะล้มเหลวในวันที่ 19 มกราคม 2038 3:14:08 หรือไม่

ฉันกังวลเล็กน้อยเกี่ยวกับเรื่องนี้ มันเรียกว่า "ปัญหาปี 2038" เคอร์เนล Linux หรือ Ubuntu พร้อมที่จะจัดการกับวันที่หลังจากนี้หรือไม่ ณ วันที่ 12.04

ไม่มันจะไม่ล้มเหลว ในกรณีที่เลวร้ายที่สุดจากมุมมองของโปรแกรมเมอร์มันจะทำงานได้ตามที่คาดไว้: มันจะถูกเปลี่ยนเป็นวันที่ 1901-12-13 20:45:52:

ในกรณีนี้คุณจะไม่อัปเดตการแจกจ่ายปัจจุบันของคุณจนกว่าจะเกิดเหตุการณ์นี้ขึ้น "การอัปเดตเป็นเรื่องง่ายหนึ่งในการอัปเดตเหล่านี้จะมีการแก้ไข " เช่นเดียวกับchocobaiกล่าว

ฉันจำได้ว่ามันเป็นปัญหา / คำถามเดียวกันกับเครื่อง 16 บิตก่อนปี 2000 และในที่สุดก็ไม่มีปัญหาใด ๆ

ทางออกจาก Wikipedia:

ระบบปฏิบัติการส่วนใหญ่ออกแบบมาเพื่อทำงานบนฮาร์ดแวร์ 64 บิตแล้วใช้time_tจำนวนเต็ม64 บิตที่ลงชื่อแล้ว การใช้ค่า 64 บิตที่ได้รับการลงนามจะแนะนำวันที่ใหม่ซึ่งมีอายุมากกว่ายี่สิบเท่าของอายุโดยประมาณของจักรวาล: ประมาณ 292 พันล้านปีจากนี้ไปจนถึงเวลา 15:30:08 น. ในวันอาทิตย์ที่ 4 ธันวาคม 292,277,026,596 ความสามารถในการคำนวณในวันที่ถูก จำกัด ด้วยความจริงที่ว่าtm_yearใช้ค่า int 32 บิตที่ลงนามเริ่มต้นที่ 1900 สำหรับปี สิ่งนี้ จำกัด ปีสูงสุดที่ 2,147,485,547 (2,147,483,647 + 1900) แม้ว่าวิธีนี้จะช่วยแก้ปัญหาสำหรับการดำเนินการโปรแกรม แต่ก็ไม่ได้แก้ปัญหาการจัดเก็บค่าวันที่ในไฟล์ข้อมูลไบนารีซึ่งส่วนใหญ่ใช้รูปแบบการจัดเก็บข้อมูลที่เข้มงวด นอกจากนี้ยังไม่สามารถแก้ปัญหาสำหรับโปรแกรม 32 บิตที่ทำงานภายใต้ชั้นเข้ากันได้และไม่อาจแก้ปัญหาสำหรับโปรแกรมที่ไม่ถูกต้องในการจัดเก็บค่าของเวลาในตัวแปรประเภทอื่น ๆ time_tกว่า

ฉันใช้ Ubuntu 13.04 กับ 64 บิตและด้วยความอยากรู้อยากเห็นฉันเปลี่ยนเวลาเป็น 2038-01-19 03:13:00 ด้วยตนเอง หลังจาก 03:14:08 ไม่มีอะไรเกิดขึ้น:

ดังนั้นจึงไม่มีอะไรต้องกังวลเกี่ยวกับปัญหานี้

เพิ่มเติมเกี่ยวกับ:

• ปี 2038 ปัญหา - วิกิพีเดีย
• จุดสิ้นสุดของเวลา (Unix) - Numberphile

คุณสามารถตรวจสอบว่าเวลาในคอมพิวเตอร์ของคุณจะพังหรือไม่โดยใช้สคริปต์ Perl ต่อไปนี้:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

หากคอมพิวเตอร์ของคุณดีคุณจะได้รับสิ่งนี้:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

หากคอมพิวเตอร์ของคุณเป็นเหมือนของฉันมันจะล้อมรอบดังนี้:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

มันสามารถทำสิ่งนี้:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

ฉันเขียนและตีพิมพ์บทความสั้น ๆ เกี่ยวกับเรื่องนี้ในปี 1996 ซึ่งรวมถึงโปรแกรม C สั้น ๆ เพื่อแสดงให้เห็น ฉันมีอีเมลกับ David Mills เกี่ยวกับปัญหาที่คล้ายกันกับ NTP - Network Time Protocol ใน Ubuntu 14.04 64- บิตแล็ปท็อปของฉันรหัส perl ไม่แสดงข้อ จำกัด ดังนั้น libs 64- บิตพื้นฐานจะต้องได้รับการแก้ไข

อย่างไรก็ตามการรันโค้ดทดสอบที่ผ่านมานานของฉันจะแสดงเวลาที่ย้อนกลับไปสู่ยุค UNIX ดังนั้นไม่ใช่ทั้งหมดที่ดีกับรหัส 32 บิตจากที่ผ่านมา

กระดาษ 1996 ของฉันเวลา UNIX จะหมดในปี 2038! อยู่ในเว็บไซต์ของฉันมาตั้งแต่ประมาณปี 2000 ตัวแปรของหัวข้อนี้ "เวลา UNIX" ได้รับการเผยแพร่ในปี 1998 ใน "วิธีปฏิบัติที่ดีที่สุดปี 2000 สำหรับคอมพิวเตอร์มิลเลนเนียม Y2K" ไอ 0136465064

64-bit Linux พร้อมอย่างน้อยถ้าคุณกำลังพูดถึงส่วนติดต่อหลักของระบบปฏิบัติการ (แน่นอนว่าแอพพลิเคชั่นแต่ละตัวยังสามารถขันได้) time_t ถูกกำหนดแบบดั้งเดิมเป็นนามแฝงสำหรับ "long" และ "long" บน 64-bit linux คือ 64- บิต

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

แม้ว่าจะมีบางระดับของความเข้ากันได้ย้อนหลังไบนารีทั้งหมดที่ต้องการรับเวลาที่ถูกต้องจะต้องถูกสร้างใหม่เพื่อใช้อินเตอร์เฟสเวลา 64 บิตใหม่

มีการทำงานบางอย่างเสร็จแล้ว (ดูตัวอย่างhttps://lwn.net/Articles/643234/และhttp://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ) แต่เรายังไม่เข้าใจ ยังคงเป็นทางยาวจากโซลูชันที่สมบูรณ์ ยังไม่ชัดเจนว่าจะมีจุดประสงค์ทั่วไป 32- บิตที่ปลอดภัย Y2K38 หรือไม่