อธิบาย Unix Timestamp และปัญหาปี 2038 (Year 2038 Problem)

วันที่ 19 มกราคม 2038 เวลา 03:14:07 UTC พอดี ระบบคอมพิวเตอร์จำนวนมากจะเจอสิ่งที่เทียบได้กับ “โอเวอร์โฟลว์ของวันที่” — หรือพูดง่าย ๆ คือ Y2K เวอร์ชัน Unix timestamp

สาเหตุไม่ได้ลึกลับหรือซับซ้อน มันมาจากการตัดสินใจหนึ่งอย่างในยุคแรกของ Unix: เก็บเวลาปัจจุบันไว้เป็นจำนวนเต็ม 32 บิต แบบ signed ซึ่งเป็นทางเลือกที่สมเหตุสมผลในปี 1970 แต่พอถึงปี 2038 มัน “เต็ม” และเก็บต่อไม่ได้

ถ้าต้องการดูว่า timestamp ตอนนี้หมายถึงวันเวลาอะไร Unix Timestamp Converter สามารถแปลงค่าใด ๆ — รวมถึงค่าที่มีปัญหา 2,147,483,647 — ให้เป็นวันที่อ่านออกทันที

Unix timestamp ทำงานอย่างไร

Unix timestamp คือจำนวนวินาทีที่ผ่านไปนับจาก 1 มกราคม 1970 เวลา 00:00:00 UTC จุดเริ่มนี้เรียกว่า Unix epoch

ปัจจุบัน timestamp อยู่แถว ๆ 1,712,000,000 — ตัวเลข 10 หลักที่เพิ่มขึ้นทีละ 1 ทุกวินาที

Timestamp ถูกใช้แทบทุกที่ในงานคอมพิวเตอร์: server logs, API responses, database records, authentication tokens, metadata ของระบบไฟล์ และส่วนภายในของระบบปฏิบัติการ รูปแบบนี้สะดวกเพราะเลขจำนวนเต็มตัวเดียวแทน “ช่วงเวลา” ที่แม่นยำได้ เปรียบเทียบ/เรียงลำดับง่าย และไม่ผูกกับโซนเวลา

จำนวนเต็ม 32 บิตเก็บได้แค่ไหน

จำนวนเต็ม 32 บิตแบบ signed เก็บค่าได้ตั้งแต่ −2,147,483,648 ถึง 2,147,483,647

สมัย Unix ถูกพัฒนา timestamp ถูกเก็บเป็นจำนวนเต็ม 32 บิตแบบ signed ค่าสูงสุด — 2,147,483,647 — ตรงกับเวลา 03:14:07 UTC ของวันที่ 19 มกราคม 2038

หลังจากนั้นอีก 1 วินาที ตัวนับจะโอเวอร์โฟลว์ เพราะ signed 32 บิตเก็บค่า 2,147,483,648 ไม่ได้ จึง “วนกลับ” ไปเป็นค่าลบมากที่สุด: −2,147,483,648 เมื่อเอาไปตีความเป็น Unix timestamp เลขลบนี้หมายถึงเวลา 20:45:52 UTC ของวันที่ 13 ธันวาคม 1901

ผลลัพธ์ในเชิงปฏิบัติ: ระบบใดก็ตามที่เก็บ timestamp เป็น signed 32 บิตและไม่รองรับโอเวอร์โฟลว์นี้ จะเริ่มแสดงวันที่ย้อนกลับไปปี 1901 เมื่อถึงปี 2038

ทำไม Y2K ถึงเป็นการเปรียบเทียบที่เข้าใจง่าย

หลายคนเคยได้ยิน Y2K — ความกังวลว่าสystem ที่เก็บปีเป็นเลข 2 หลัก (99 = 1999) จะพังเมื่อเปลี่ยนเป็น 00 ซึ่งอาจถูกตีความเป็น 1900 แทน 2000

ปัญหาปี 2038 คล้ายกันในเชิงโครงสร้าง:

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

ต่างกันตรงขนาดผลกระทบ Y2K กระทบหลัก ๆ ที่สตริงวันที่และ field ปี 2 หลักในแอปฯ ส่วนปัญหา 2038 กระทบชนิดข้อมูลพื้นฐาน (จำนวนเต็ม 32 บิต) ที่ถูกใช้ระดับระบบปฏิบัติการบนแพลตฟอร์มจำนวนมหาศาล

ระบบไหนเสี่ยงจริง

ไม่เสี่ยง:

ระบบปฏิบัติการ 64 บิตสมัยใหม่ (Linux, macOS, Windows บนฮาร์ดแวร์ 64 บิต) — ใช้การแทนเวลาแบบ 64 บิต
แอปพลิเคชันสมัยใหม่ส่วนใหญ่ที่ทำงานบนแพลตฟอร์ม 64 บิต
ระบบใหม่หลังปี 2000 ที่ใช้จำนวนเต็ม 64 บิตมาตั้งแต่ต้น

อาจเสี่ยง:

ระบบ embedded ที่รันบนโปรเซสเซอร์ 32 บิต — พบได้ทั่วไปในอุปกรณ์อุตสาหกรรม เครื่องมือแพทย์ ระบบรถยนต์ อุปกรณ์เครือข่าย และอิเล็กทรอนิกส์ผู้บริโภค
ซอฟต์แวร์ legacy ที่คอมไพล์สำหรับระบบ 32 บิตซึ่งเก็บ timestamp เป็น time_t และไม่เคยอัปเดต
ฐานข้อมูลเก่าที่คอลัมน์ timestamp ถูกกำหนดเป็นจำนวนเต็ม 32 บิต
ระบบไฟล์ที่เก็บเวลาการแก้ไขไฟล์เป็นค่า 32 บิต (เช่น ext3 บน Linux มีข้อจำกัดนี้)
บางโปรโตคอลเครือข่ายที่เข้ารหัส timestamp ไว้ใน field 32 บิต

กลุ่ม embedded น่ากังวลเป็นพิเศษ เพราะอุปกรณ์เหล่านี้มักมีอายุใช้งานยาวนาน รันระบบปฏิบัติการแบบตัดทอน ไม่มีการอัปเดตอัตโนมัติ และการอัปเกรด/เปลี่ยนทดแทนอาจไม่คุ้มค่า

ผลกระทบในโลกจริง

ระบบอุตสาหกรรมและโครงสร้างพื้นฐาน

ระบบควบคุมไฟฟ้า ระบบบำบัดน้ำ โรงงาน และระบบบริหารอาคาร มักรันบนฮาร์ดแวร์ embedded ที่ใช้งานกันเป็นสิบปี PLC ที่ติดตั้งปี 2005 และใช้เฟิร์มแวร์ 32 บิตอาจยังทำงานอยู่ในปี 2038 และอาจทำงานผิดปกติเมื่อ timestamp โอเวอร์โฟลว์

ระบบการเงิน

ระบบธนาคารและเทรดจำนวนมากยังมีซอฟต์แวร์ legacy บนเมนเฟรมหรือแพลตฟอร์ม 32 บิตเก่า หากมีการเก็บ timestamp ธุรกรรมเป็นจำนวนเต็ม 32 บิต อาจได้ timestamp ที่ผิด หรือระบบอาจปฏิเสธธุรกรรมที่คำนวณวันที่เลยจุดโอเวอร์โฟลว์

อุปกรณ์ IoT

ไมโครคอนโทรลเลอร์ราคาถูกและประหยัดพลังงานทำให้มีอุปกรณ์ IoT จำนวนมหาศาลที่ใช้การแทนเวลาแบบ 32 บิตถูกติดตั้งและจะยังอยู่เกินปี 2038 เราเตอร์บ้าน อุปกรณ์สมาร์ทโฮม เซนเซอร์อุตสาหกรรม — หลายตัวรัน Linux kernel 32 บิตหรือเฟิร์มแวร์ bare‑metal โดยไม่มีการป้องกันปี 2038

ระบบไฟล์

Metadata ของไฟล์ — เวลาสร้าง แก้ไข เข้าถึง — ถูกเก็บโดยระบบปฏิบัติการ ถ้าระบบใช้ field เวลาแบบ 32 บิตสำหรับ metadata หลังโอเวอร์โฟลว์ไฟล์อาจดูเหมือนแก้ไขเมื่อปี 1901 สิ่งนี้จะทำให้ซอฟต์แวร์แบ็กอัป ระบบเวอร์ชันคอนโทรล และทุกอย่างที่ใช้เวลาแก้ไขไฟล์เพื่อเปรียบเทียบ “พัง” ได้

แล้วระบบ 64 บิตล่ะ?

จำนวนเต็ม 64 บิตแบบ signed เก็บค่าได้ถึง 9,223,372,036,854,775,807

ถ้าเอาไปตีความเป็น Unix timestamp ค่าสูงสุดนั้นหมายถึงปี 292,277,026,596 ดังนั้นในทางปฏิบัติไม่มีความกังวลเรื่อง “พื้นที่ timestamp หมด” สำหรับระบบ 64 บิต — จักรวาลจะสิ้นสุดไปก่อนที่จะถึงตัวเลขนั้นเสียอีก

ระบบปฏิบัติการสมัยใหม่ส่วนใหญ่ย้ายไปใช้การแทนเวลาแบบ 64 บิตมานานก่อนปี 2038:

Linux บนฮาร์ดแวร์ 64 บิตใช้ time_t 64 บิตตั้งแต่ต้นทศวรรษ 2000
Linux บนฮาร์ดแวร์ 32 บิตแก้ปัญหานี้ใน kernel 5.6 (ปี 2020) ด้วยอินเทอร์เฟซเวลา 64 บิตบนระบบ 32 บิต
macOS ย้ายไปใช้เวลา 64 บิตใน OS X 10.6 (2009)
Windows ใช้โครงสร้าง FILETIME แบบ 64 บิต ซึ่งปลอดภัยไกลเกินปี 30,000

ความเสี่ยงที่ยังเหลือมักอยู่ในระบบที่ “จงใจ” เก็บ timestamp ในคอลัมน์จำนวนเต็ม 32 บิตของฐานข้อมูล หรือ field โปรโตคอลเครือข่ายที่นิยามไว้เป็น 32 บิต แทนที่จะอาศัย time_t ของระบบปฏิบัติการ

วิธีแก้

แนวคิดของวิธีแก้ง่ายมาก: เปลี่ยนการเก็บ timestamp แบบ 32 บิตเป็น 64 บิต แต่ในทางปฏิบัติต้องทำหลายอย่าง:

1. อัปเดตชนิดข้อมูลในโค้ดที่ใช้เก็บ timestamp (int32_t หรือ time_t บน 32 บิต → int64_t หรือ time_t บน 64 บิต) 2. ย้ายคอลัมน์ฐานข้อมูลจากจำนวนเต็ม 32 บิตหรือ field TIMESTAMP (ซึ่งมักเป็น 32 บิตใน MySQL รุ่นเก่าและระบบคล้ายกัน) ไปเป็นทางเลือกแบบ 64 บิต 3. อัปเดตการ implement โปรโตคอลเครือข่ายที่มี field timestamp 32 บิตเป็นส่วนหนึ่งของสเปก 4. คอมไพล์ใหม่หรือเปลี่ยนเฟิร์มแวร์ในอุปกรณ์ embedded

สำหรับซอฟต์แวร์บนแพลตฟอร์ม 64 บิต การแก้มักง่ายแค่คอมไพล์ใหม่ให้ใช้ time_t แบบ 64 บิต ส่วน embedded บนฮาร์ดแวร์ 32 บิตอาจต้องเปลี่ยนฮาร์ดแวร์

ปริมาณงานที่ต้องใช้ต่างกันมาก แอปเว็บที่ดูแลดีบนโครงสร้างพื้นฐานสมัยใหม่อาจแทบไม่ต้องแก้อะไร แต่ระบบควบคุมอุตสาหกรรมแบบเก่าที่มีเฟิร์มแวร์เฉพาะและไม่มีทีมพัฒนาที่ active จะยากกว่ามาก

เรายังมีเวลาอีกนานแค่ไหน?

ในช่วงเวลาที่เขียน (เมษายน 2026) ยังเหลือประมาณ 12 ปีจนถึงวันที่ 19 มกราคม 2038

ฟังดูเหมือนพอ สำหรับระบบที่ยังบำรุงรักษาอยู่ก็น่าจะพอจริง ๆ เพราะแนวทางแก้เป็นที่เข้าใจกันดีและวางแผนได้

แต่สำหรับระบบที่ถูกทิ้งร้าง อุปกรณ์ embedded ที่ไม่ได้รับการดูแล และโครงสร้างพื้นฐานเก่าบนฮาร์ดแวร์ 32 บิต — 12 ปีไม่ได้นานนัก อุปกรณ์ที่อัปเดตยากที่สุดก็มักเป็นอุปกรณ์ที่มีโอกาสยังใช้งานอยู่ในปี 2038 มากที่สุด

องค์กรที่ควรกังวลที่สุดคือองค์กรที่มีระบบ embedded 32 บิตในโครงสร้างพื้นฐานสำคัญ และนั่นก็มักเป็นองค์กรที่มีโอกาสน้อยที่สุดที่จะมีงบประมาณและความรู้ภายในในการแก้เชิงรุก

ปัญหาปี 2038 จะไม่ทำให้เครื่องบินตกจากฟ้าในวันที่ 19 มกราคม 2038 แต่บางระบบจะทำงานผิด บาง log จะมี timestamp ที่ไร้ความหมาย และอุปกรณ์บางประเภทจะต้องได้รับการแก้ไขแบบเร่งด่วน ยิ่งคุณเข้าใกล้โครงสร้างพื้นฐานสำคัญบนฮาร์ดแวร์ 32 บิตมากเท่าไร ก็ยิ่งควรตรวจเช็กตั้งแต่ตอนนี้มากกว่ารอถึงวันนั้น