เวลาที่ผ่านไปนับจาก Epoch

 (aphyr.com)
2 คะแนน โดย GN⁺ 2024-12-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • วินาทีนับจาก Epoch

    • เป็นที่ทราบกันโดยทั่วไปว่าเวลา POSIX หรือเวลา Unix หมายถึงจำนวนวินาทีหลังจากวันที่ 1 มกราคม 1970 00:00:00 แต่คำอธิบายนี้ไม่แม่นยำนัก ตัวอย่างเช่น เวลา POSIX ของ 25 ธันวาคม 2024 18:54:53 UTC คือ 1735152686 ซึ่งน้อยกว่าจำนวนวินาทีที่ผ่านไปจริง 1735152715 อยู่ 29 วินาที

    • เวลา POSIX ถูกนิยามต่อยอดจากเวลาสากลเชิงพิกัด (UTC) ใน IEEE 1003.1 มาตรฐานนี้สมมติว่าแต่ละวันมีความยาวเท่ากับ 86,400 วินาทีพอดี แต่ในความเป็นจริง ความยาวของหนึ่งวันไม่ได้เท่ากับ 86,400 วินาทีและเปลี่ยนแปลงไปตามกาลเวลา เพื่อชดเชยเรื่องนี้ นักดาราศาสตร์จึงประกาศเพิ่ม leap second ให้กับ UTC เป็นระยะ

  • โบราณคดี

    • ภาคผนวก B ของ IEEE 1003 มีการอภิปรายที่น่าสนใจเกี่ยวกับ leap second ในช่วงเวลาที่มาตรฐานฉบับนี้เผยแพร่ มีการเพิ่ม leap second ไปแล้ว 14 ครั้งนับจากวันที่ 1 มกราคม 1970 leap second เหล่านี้ถูกละเลยเพื่อให้คำนวณความต่างของเวลาได้ง่ายขึ้น

    • ระบบส่วนใหญ่มองว่าเวลาเป็นค่าที่เพิ่มขึ้นอย่างต่อเนื่อง แต่ระบบส่วนใหญ่ไม่ได้ติดตาม leap second และไม่ได้ซิงก์กับแหล่งอ้างอิงเวลามาตรฐาน ดังนั้นข้อกำหนดที่วินาทีนับจาก Epoch ต้องแสดงจำนวนวินาทีระหว่างเวลาที่อ้างอิงกับ Epoch ได้อย่างแม่นยำจึงไม่เหมาะสม

    • การตีความวินาทีนับจาก Epoch อย่างสอดคล้องกันอาจมีความสำคัญต่อแอปพลิเคชันแบบกระจายบางประเภท การสะสมของ leap second นั้นคาดการณ์ไม่ได้ และจำนวน leap second หลังจาก Epoch ก็มีแนวโน้มจะเพิ่มขึ้น

  • สิ่งที่ควรทำแทน

    • หากต้องการคำนวณระยะเวลาระหว่างสองเหตุการณ์บนคอมพิวเตอร์เครื่องเดียว ควรใช้ CLOCK_MONOTONIC หากไม่จำเป็นต้องแลกเปลี่ยนเวลา POSIX กับระบบอื่น ก็สามารถใช้ TAI, GPS หรือ LORAN ได้

    • หากต้องการการจัดแนวโดยประมาณกับระบบ timestamp แบบ POSIX ก็สามารถกระจาย leap second ออกไปบนช่วงเวลาที่ยาวขึ้นได้ ไลบรารีอย่าง qntm ของ t-a-i รองรับการแปลงระหว่าง POSIX กับ TAI

    • ขณะนี้มีความพยายามที่จะยกเลิก leap second และหวังว่าจะเสร็จสิ้นภายในปี 2035 ซึ่งจะต้องมีงานเพิ่มในการสร้างตารางแปลงสำหรับทุกสิ่งที่ตั้งอยู่บนสมมติฐานว่า "หนึ่งวันมี 86,400 วินาที" แต่จะทำให้การถามหาจำนวนวินาทีระหว่างเวลาสองช่วงง่ายขึ้น อย่างน้อยก็สำหรับเวลาหลังปี 2035

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-27
ความคิดเห็นจาก Hacker News

  • เคยอ่านนิยายวิทยาศาสตร์เรื่อง "A Deepness in the Sky" และรู้สึกว่าน่าสนใจกับการกล่าวถึงวินาทีหลัง epoch ในหนังสือ

    • วิธีการวัดเวลาของ Qeng Ho มีความซับซ้อน โดยเริ่มนับวินาทีจากช่วงเวลาที่มนุษย์เหยียบดวงจันทร์เป็นครั้งแรก
    • จุดเริ่มต้นจริง ๆ อยู่หลังจากนั้นราว 15 ล้านวินาที ซึ่งเป็นเวลา 0 วินาทีของระบบปฏิบัติการคอมพิวเตอร์ยุคแรก

  • มีความพยายามที่จะยกเลิก leap second และหวังว่าจะเสร็จสิ้นภายในปี 2035

    • จุดประสงค์ของ UTC คือการอยู่ห่างจาก TAI เป็นจำนวนวินาทีเต็ม เพื่อประมาณค่าเวลาเฉลี่ยสุริยะ
    • ถ้าไม่ต้องการติดตาม MST ก็ควรเปลี่ยนไปใช้ TAI และเมื่อ UTC เบี่ยงออกจาก MST แล้ว leap second ในอดีตก็จะหมดความหมาย

  • "UTC epoch" สมัยใหม่คือวันที่ 1 มกราคม 1972

    • ปลายปี 1971 มีการกระโดดแบบไม่สม่ำเสมอ 0.107758 วินาที TAI และหลังจากนั้นอัตรา tick ของ UTC ก็ถูกปรับให้ตรงกับ TAI อย่างแม่นยำ
    • Unix time ของปี 1970 และ 1971 จริง ๆ แล้วไม่ตรงกับเวลา UTC ของช่วงนั้น

  • ทุกครั้งที่อ่านเรื่องการวัดเวลา ก็มักจะได้เรียนรู้อะไรใหม่ ๆ

    • เคยคิดว่า Unix time เป็นวิธีติดตามเวลาที่ง่ายที่สุด
    • คิดว่าไม่มี leap second เข้ามาเกี่ยว แต่ดูเหมือนจะยังคิดไม่รอบด้านพอ

  • ไม่นานมานี้ได้ทำงานกับโค้ดที่รันบน VAX หรือบน OpenVMS และเพิ่งเห็นเป็นครั้งแรกว่า epoch คือวันที่ 17 พฤศจิกายน 1858

    • ในโค้ดมีการ abstract ไว้เป็น Unix epoch

  • มีบางช่วงเวลาที่ไม่สามารถแสดงเป็น POSIX timestamp ได้ และบาง POSIX timestamp ก็ไม่ตรงกับเวลาจริง

  • คิดว่าบทความนี้ทำลายคริสต์มาสไปแล้ว

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

  • เวลาเก็บวันที่ในฐานข้อมูล จะเก็บเป็น Unix epoch time เสมอ และเก็บข้อมูลเขตเวลาแยกต่างหาก

    • กำลังคิดว่าอาจจะดีกว่าถ้าเก็บ timestamp ในรูปแบบ TAI แล้วค่อยแปลงเป็น UTC เมื่อจำเป็น
    • เขตเวลาเป็นแนวคิดที่มนุษย์สร้างขึ้น และมีการปรับเปลี่ยนไปตามกาลเวลา
    • ควรยึดเวลาแบบสัมบูรณ์เป็นหลัก แล้วค่อยแปลงเป็นรูปแบบเวลาท้องถิ่นเมื่อจำเป็น

  • เมื่อประมาณ 10 ปีก่อน เคยได้ยินในงานประชุมว่า Google ไม่ใช้ leap second แต่กระจายมันออกไปในวินาทีปกติ

    • Google ปรับแต่งเซิร์ฟเวอร์ NTP เพื่อกระจาย leap second

  • สงสัยว่ามีวิธีวัดเวลาที่ทั้งซิงก์กันและเพิ่มขึ้นแบบ monotonic หรือไม่