Timestamp ปัญหาปี 2038 สำหรับระบบ Ubuntu 64 บิต

ฉันใช้ระบบ Ubuntu 64 บิต

ฉันกำลังทำงานในโครงการที่รวม MariaDB ฉันวางแผนที่จะแนะนำเทคนิคการประทับเวลาในโครงการเพื่อให้ผู้คนได้รับเวลาที่ถูกต้องสำหรับเขตเวลาที่แตกต่างกัน

ฉันเคยได้ยินและอ่านบทความเกี่ยวกับปัญหาปี 2038 สำหรับการประทับเวลา บทความจำนวนมากแนะนำให้เราใช้ระบบ 64 บิตเพื่อซื้อเวลาเพิ่มขึ้นอีกเล็กน้อย

"บิต" นี้หมายถึงเวลาเท่าไหร่? มันนานพอที่เราจะสามารถจัดการเว็บแอปพลิเคชันจนกว่าจะสิ้นสุดหรือไม่ หากไม่ใช่ในกรณีนี้จะเป็นเพียงการขยายเวลาสองปีเท่านั้นดังนั้นเมื่อถึงปี 2040 เราจะมีแอปพลิเคชันที่ทำงานไม่เหมาะสมหรือไม่?

14.04 64-bit time

— Tet
แหล่งที่มา

ระบบ 64 บิตที่ใช้time_tจำนวนเต็ม64 บิตจะทำให้คุณมีเวลามากขึ้น - จนถึง 15:30:08 น. ในวันอาทิตย์ที่ 4 ธันวาคม 292,277,026,596 หวังว่ามันจะนานพอสำหรับการสมัครของคุณ;)

— Ron

มันไม่ได้ทำให้คุณเพิ่มอีกสักนิด มันให้คุณมากกว่า 32 บิต

— 12205

การประทับเวลา 64 บิตเป็นอีกหนึ่งมาตรการการหยุดชั่วคราว ผู้คนที่ทำงานในโครงการยูโทเปียใน 100,000,000,000,000 CE เป็นอย่างไร พวกเขากำลังต้องการระบบคอมพิวเตอร์ที่ใช้งานได้เช่นกัน! การใช้การประทับเวลาแบบ 128 บิตจะทำให้เราสามารถระบุได้ตลอดเวลาไม่เพียง แต่จากการวนซ้ำของเอกภพเท่านั้น แต่ยังมีอีกมากมาย

— แบล็กไลท์ส่องแสง

ในขณะที่คุณไม่เคยได้รับการยอมรับคำตอบใด ๆ ก่อนที่ในเว็บไซต์นี้: หากหนึ่งในคำตอบที่อยู่ด้านล่างช่วยให้คุณไม่ลืมที่จะคลิกสีเทา☑ที่ด้านซ้ายของข้อความซึ่งหมายความว่าใช่คำตอบนี้ถูกต้อง ! ;-)

— Fabby

คำตอบ:

ถ้ามีตัวเลือกในการซื้อ "บิต" อย่างแท้จริงนั่นคือโอนจากจำนวนเต็ม 32 บิตที่ได้รับการรับรองไปเป็นจำนวนเต็ม 32 บิตที่ไม่ได้ลงนามสิ่งต่าง ๆ ยังคงทำงานอยู่ใน 2106

การถ่ายโอนเป็น 64 บิตนั้นค่อนข้าง "ดีกว่า" คุณได้รับความละเอียดหลายร้อยพันล้านปี

และ Ubuntu ทำสิ่งนี้:

$ uname -p
x86_64

$ date --date=9090-01-01 +%s
224685532800

อย่างไรก็ตามนั่นคือระดับระบบปฏิบัติการ เพียงเพราะ Ubuntu ใช้จำนวนเต็ม 64 บิตในช่วงเวลานั้นไม่ได้หมายความว่า MySQL / MariaDB จะใช้เพื่อจัดเก็บการประทับเวลา หากวันที่ผ่านมา 2581 มีความสำคัญต่อคุณให้เริ่มการทดสอบทันที

ที่จริงฉันสามารถช่วยคุณได้ในบางครั้ง มันยังพังอยู่ ข้อผิดพลาดนี้ถูกรายงานในช่วงทศวรรษที่ผ่านมาแต่การทดสอบหลักยังคงล้มเหลวด้วย 64 บิต int

mysql> select from_unixtime(2548990800);
+---------------------------+
| from_unixtime(2548990800) |
+---------------------------+
| NULL                      |
+---------------------------+
1 row in set (0.00 sec)

นี่ไม่ใช่แม้แต่ที่เก็บข้อมูล มันน่าสมเพชเล็กน้อย

(และใช่ที่ทำงานบน MariaDB เวอร์ชัน 10.1)

— Oli
แหล่งที่มา

10 ปีที่ผ่านมาพวกเขายังคงมี 22 ปีในการแก้ไข <นิ้วไขว้> ...

— Mindwin

หมายเหตุ: ใช้ไม่ได้ลงนาม 32 จำนวนเต็มบิตสับ

— เควิน

อย่าเก็บเป็นจำนวนเต็มเลย เก็บไว้เป็นสตริงวันที่จัดรูปแบบISO 8601 นี่เป็นรูปแบบมาตรฐานที่ใช้ผ่านอินเทอร์เน็ต

9999-12-31T23:59:59+00:00

— dobey
แหล่งที่มา

ให้ทุกคนยกแก้วเป็น Bug ปี 10K! ;) แต่ในความจริงจังในขณะที่สตริงยืดออกได้จริง ๆ พวกมันค่อนข้างใหญ่ (ตัวอย่างของคุณคือ 200 บิต!) และการวิเคราะห์และจัดการตัวเลขดั้งเดิมนั้นเร็วกว่าเป็นพันล้านครั้ง ที่สำคัญ.

— Oli

นี่เป็นรูปแบบที่ยอดเยี่ยมสำหรับการแสดง - และสำหรับสิ่งนั้นเท่านั้น สำหรับสิ่งอื่น ๆ (นั่นคือการจัดการข้อมูลจนถึงช่วงเวลาสุดท้ายเมื่อคุณตัดสินใจที่จะจัดรูปแบบให้กับผู้ใช้) เช่นการเปรียบเทียบการทำ arithmetics ฯลฯ การประทับเวลา Unix เป็นจำนวนเต็ม (หรือลอย) จะดีกว่ามาก

— egmont

@Oli มันสำคัญถ้ามันสำคัญจริงๆ วิธีนี้จะไม่ล้มเหลวเมื่อมีเวลาเก่ากว่ายุค UNIX รูปแบบเป็นมาตรฐานที่ใช้สำหรับวันที่ทั่วอินเทอร์เน็ตในโปรโตคอลและ API หากคุณกำลังจัดเก็บบางอย่างในคอลัมน์ MariaDB จริงๆแล้วมันเป็นวิธีที่คุณควรเก็บไว้ในดิสก์ แน่นอนว่าในหน่วยความจำคุณอาจต้องการเก็บไว้ในโครงสร้างข้อมูลที่คล้อยตามได้ และคุณไม่จำเป็นต้องใช้ 40 บิตสุดท้ายหากคุณใช้ UTC อยู่เสมอ

— dobey