ไม่มีการเพิ่มวินาทีอธิกสุรทินในช่วงปลายเดือนธันวาคม 2026

 (datacenter.iers.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตาม IERS Bulletin C 72 จะไม่มีการเพิ่มวินาทีอธิกสุรทินให้กับ UTC ในช่วงปลายเดือนธันวาคม 2026 ดังนั้นระบบวัดและกระจายเวลาจึงไม่จำเป็นต้องเตรียมการแทรกค่าเพิ่มเติมเป็นพิเศษ
  • ความต่างระหว่าง UTC และ TAI จะคงอยู่ที่ UTC-TAI = -37 s ตั้งแต่ 00:00 UTC ของวันที่ 1 มกราคม 2017 ไปจนกว่าจะมีประกาศเพิ่มเติม
  • การจะมีการนำวินาทีอธิกสุรทินมาใช้หรือไม่นั้นตัดสินจาก การเปลี่ยนแปลงของ UT1-TAI และช่วงเวลาที่เป็นไปได้คือปลายเดือนมิถุนายนหรือปลายเดือนธันวาคม
  • Bulletin C จะประกาศ time step ของ UTC ทุก 6 เดือน หรือยืนยันว่า ไม่มี time step ในวันที่เป็นไปได้ถัดไป
  • การเผยแพร่ UTC ช่วงปลายปี 2026 ไม่จำเป็นต้องใช้ค่าชดเชยใหม่ และยังคงใช้ความสัมพันธ์ UTC-TAI = -37 s เดิมต่อไปได้

ประกาศ UTC ใน IERS Bulletin C 72

  • IERS ระบุใน Bulletin C 72 ที่เผยแพร่ในปารีสเมื่อวันที่ 6 กรกฎาคม 2026 ว่าจะไม่มีการนำวินาทีอธิกสุรทินมาใช้ในช่วงปลายเดือนธันวาคม 2026
  • ประกาศนี้มุ่งไปยัง หน่วยงานที่รับผิดชอบการวัดและการกระจายเวลา
  • ค่าหลักมีอยู่ 2 รายการดังนี้
    • ตั้งแต่ 00:00 UTC ของวันที่ 1 มกราคม 2017 ไปจนกว่าจะมีประกาศเพิ่มเติม UTC-TAI = -37 s
    • ไม่มี time step ใหม่ใน UTC ช่วงปลายเดือนธันวาคม 2026

การตัดสินใจเรื่องวินาทีอธิกสุรทินและรอบการประกาศ

  • วินาทีอธิกสุรทินอาจถูกนำมาใช้กับ UTC ตาม การเปลี่ยนแปลงของ UT1-TAI
  • ช่วงเวลาที่สามารถนำมาใช้ได้คือทุกปีใน ปลายเดือนมิถุนายน หรือ ปลายเดือนธันวาคม
  • Bulletin C จะเผยแพร่ทุก 6 เดือน
    • หาก UTC มี time step ก็จะประกาศเรื่องนั้น
    • หากไม่มี time step ในวันที่เป็นไปได้ถัดไป ก็จะยืนยันเรื่องนั้น

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

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

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

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

    • ตอบสั้นๆ คือใช่ สภาพอากาศ กิจกรรมทางธรณีวิทยา รวมถึงการเคลื่อนย้ายน้ำโดยมนุษย์ เช่น การสูบน้ำบาดาล การสร้างเขื่อน และการละลายของธารน้ำแข็งกับน้ำแข็ง ล้วนทำให้คาบการหมุนและแกนหมุนของโลกเปลี่ยนไปในแบบที่คาดการณ์ยาก
      เท่าที่จำได้ โมเดลพวกนี้เป็นพหุนามตรีโกณมิติลำดับต่ำ ดังนั้นต่อให้ทำโมเดลความคาดเดาไม่ได้ได้สมบูรณ์ ก็ยังยากที่จะเผยแพร่ด้วยความแม่นยำสูงมากเพราะมี truncation error และมันก็ถูกใส่ไว้ในอุปกรณ์อย่างดาวเทียมอยู่แล้ว เลยทำให้ซับซ้อนตามใจไม่ได้
      อีกอย่าง leap second ก็กำลังจะหายไป และเท่าที่รู้จะถูกยกเลิกแบบค่อยเป็นค่อยไปในปี 2035 จำได้ว่าล่าช้าเพราะ Russia ต้องการเวลาอัปเดตดาวเทียม GLONASS
    • ใช่ มีปัจจัยแบบนั้นและอีกมากมาย ความแม่นยำของการวัดของเราดีกว่าอัตราการเปลี่ยนแปลงอันดับหนึ่งและอันดับสองของความยาววันในแต่ละปีมาก
      https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... เป็นกราฟที่เกี่ยวข้องกับเรื่องนี้มากที่สุด และการกระโดดขึ้นลงในแนวตั้งก็คือ leap second ส่วน IERS ก็มีกราฟของมิติอื่นๆ ของการหมุนด้วย แต่กราฟนี้ดูง่ายดี
    • พอดีไปเปิดบทความ Wikipedia เพื่อดูว่า leap second ครั้งล่าสุดถูกเพิ่มเมื่อไหร่ และคำตอบก็อยู่ในนั้นเลย
      “ความเร็วการหมุนของโลกเปลี่ยนไปตามสภาพภูมิอากาศและเหตุการณ์ทางธรณีวิทยา ดังนั้น leap second ของ UTC จึงถูกจัดวางอย่างไม่สม่ำเสมอและไม่สามารถคาดการณ์ได้อย่างแม่นยำ”
      https://en.wikipedia.org/wiki/Leap_second
    • จริงๆ แล้วเกือบจะตรงกันข้าม การหมุนของโลกอาจต่างกันได้เป็นระดับหลายวินาทีในแต่ละปี แต่เมื่อมองข้ามช่วงหลายร้อยปี ความผันผวนมักหักล้างกันเป็นส่วนใหญ่
      เลยคิดว่าการพยายามเพิ่มหรือลบ leap second ไม่ค่อยเป็นความคิดที่ดี เรื่องแบบนี้ในทางปฏิบัติมีแค่หน่วยงานด้านอวกาศที่ต้องสนใจ และพวกเขาก็ใช้ค่าชดเชยที่ต้องการเองได้โดยไม่จำเป็นต้องกระทบทุกคน
      สำหรับคนทั่วไป ผลกระทบที่เกิดขึ้นจริงจาก drift นี้คงมีประมาณ GPS แต่ GPS ก็ส่งค่าออฟเซ็ตจากนาฬิกาของตัวเองมาอยู่แล้ว ทำให้ตัวรับแก้ไขได้ นาฬิกา GPS ไม่เหมือนทั้ง UTC และ TAI
    • ดูที่ https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co... ได้

  • นี่มันออกจะเป็นข่าวที่ไม่ใช่ข่าวมากกว่าหรือเปล่า? จำลางๆ ว่าทุกวันนี้มันสร้างปัญหาให้ระบบคอมพิวเตอร์เยอะเกินไป จนเลยหยุดเพิ่ม leap second ไปก่อนจนกว่าจะมีประกาศแยก
    ตอนนี้ต่างกันอยู่ 37 วินาที และไม่มีใครต้องกังวลว่า Christmas จะเลื่อนไปอยู่แถว Easter ปัญหานี้น่าจะส่งต่อให้คนรุ่นหลังอย่างมีความรับผิดชอบได้มากกว่าปัญหาอื่นๆ อีกหลายเรื่อง
    การประกาศทุก 6 เดือนก็เป็นแค่ขั้นตอนเพื่อให้ตรงตามถ้อยคำในสนธิสัญญาระหว่างประเทศเดิม

    • ยังไม่ถึงขั้นนั้น เป็นแค่ข้อเสนอ และมีโอกาสสูงว่าจะยุติอย่างเป็นทางการก่อนปี 2035ได้ยาก
      เหตุที่ไม่มี leap second มาสักพัก เพราะ drift ระหว่าง TAI กับ UT1 ช้าลง และจริงๆ ก็กำลังเคลื่อนไปในทิศตรงข้ามอย่างช้ามาก
    • รู้สึกว่าให้เวลาประกาศแค่6 เดือนมันไม่สมเหตุสมผล และนั่นน่าจะเป็นต้นตอของปัญหา
      ต่อให้เวลาเพี้ยนไปประมาณ ±60 วินาที ก็คงไม่มีใครสังเกตเห็น ดังนั้นใส่ leap second แบบกำหนดเองสักครั้งทุก 10 ปี แล้วประกาศล่วงหน้า 10 ปีเพื่อให้ทุกคนมีเวลาจัดระบบ น่าจะบริหารจัดการได้มากกว่า การให้ทั้งโลกประสานงานกันภายใน 6 เดือนนั้นมองโลกในแง่ดีเกินไป

  • ถ้าอธิบายให้เด็ก 5 ขวบฟัง อยากรู้ว่านี่มีผลกับUNIX timestampยังไง โดยเฉพาะกับพวกที่อยู่ในโหมดบำรุงรักษาหรือแทบไม่มีคนดูแล
    งานที่ฉันทำไม่ต้องการความละเอียดระดับนี้ แต่ชัดเจนว่าต้องมีบางวงการที่ต้องใช้

    • UNIX timestamp ไม่สนใจ leap second เลยและปฏิบัติเหมือนมันไม่มีอยู่
      เพราะงั้นตอนมีการแทรก leap second ก็อาจเกิดวินาทีจริงที่อ้างอิงด้วย UNIX timestamp ไม่ได้ และตอนลบ leap second ก็อาจเกิด UNIX timestamp สำหรับวินาทีที่ไม่มีอยู่จริง
    • ทุกครั้งที่มีการเพิ่ม leap second ทาง Google จะค่อยๆ ทำให้นาฬิกาเซิร์ฟเวอร์เดินช้าลงหรือเร็วขึ้นในช่วงเวลาที่ยาวกว่าเดิม โดยปกติคือหลายชั่วโมง เพื่อค่อยๆ ให้กลับมาตรงกับนาฬิกาทรงกลมสมบูรณ์แบบที่ทำจากแพลทินัมบริสุทธิ์ซึ่งอยู่ที่ไหนสักแห่งของ NIST: https://developers.google.com/time/smear
    • ผลลัพธ์ของ time() และ clock_gettime(CLOCK_REALTIME) ได้รับผลจาก leap second
      leap second ใหม่จะมาถึงระบบผ่าน NTP น่าเสียดายที่ NTP แจกจ่ายแค่แฟล็กบอกว่าจะมี leap second แต่ไม่ได้แจกจ่ายออฟเซ็ตนั้นเอง อย่างไรก็ดี เวลาที่แจกจ่ายมาก็ได้รับผลจาก leap second อยู่แล้ว ดังนั้น NTP client จึงไม่จำเป็นต้องรู้ก็ได้
      ตรงกันข้าม วิธีซิงก์เวลาอื่นอย่าง GPS และ PTP ใช้มาตรเวลาที่ไม่ได้รับผลจาก leap second และแจกจ่ายออฟเซ็ตของ UTC เป็นข้อมูลเพิ่มเติม หน้าที่แก้ไขเวลาที่ได้รับตอนปลายทางเป็นของ client ใน kernel มีพารามิเตอร์ clock_adjtime() สำหรับ leap second อยู่
      ถ้าเป็นระบบแบบ manual ที่มี NTP client เวลาใหม่จะถูกปรับให้ตรงกับ leap second ระหว่างที่ระบบกำลังทำงาน Linux ให้ความสำคัญกับเวลา UTC เป็นหลัก จึงเก็บสิ่งนี้ไว้ในอุปกรณ์ RTC และคงอยู่หลังรีบูต
      CLOCK_TAI ดูเหมือนควรคืนค่าเวลา TAI แต่ใน Linux desktop/server distribution ทั่วไปมันถูกมองเป็นของรองชั้นถึงขั้นไม่ได้ตั้งค่าแม้แต่ออฟเซ็ต ทำให้คืนค่าเวลาเดียวกับ CLOCK_REALTIME
      ใน /etc มีไฟล์รายการ leap second ที่มาจากแพ็กเกจบางตัวอยู่ และการอัปเดตไฟล์นี้ต้องอาศัยการอัปเดตระบบ ไม่คิดว่าซอฟต์แวร์ NTP แบบดั้งเดิมจะอัปเดตแพ็กเกจนี้แบบไดนามิกได้ แต่ซอฟต์แวร์ที่ใช้ไฟล์นี้ก็มีไม่มากนัก
      ถ้ามีสคริปต์บริการ init ตัวไหน parse มันแล้วตั้งค่า kernel UTC offset ระบบก็อาจมี CLOCK_TAI ช้ากว่าโลกภายนอก 1 วินาทีจนกว่าจะอัปเดต แต่เท่าที่รู้มันไม่มีผลอะไรกับเวลา UTC ของ Linux

  • วลีว่า “ถึงหน่วยงานที่รับผิดชอบการวัดและเผยแพร่เวลา” นี่ เฉพาะทางสุดๆ

    • ที่ดียิ่งกว่าคือชื่อองค์กรนั้นคือ International Earth Rotation Service
    • หลายปีที่ผ่านมา ตำแหน่งผู้นำที่ดูแลงานผลผลิตด้านเวลาความแม่นยำสูงต่างๆ ที่ USNO คือ “Director of the Directorate of Time”
    • เป็นถ้อยคำที่เหมือนหลุดมาจากนิยายของ Douglas Adams
    • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
      แค่ชื่อตำแหน่งก็เหมือนนิยายไซไฟแล้ว

  • ถ้า UTC-TAI offset คงอยู่ที่ -37 วินาที ก็หมายความว่า UTC-GPS offset จะคงอยู่ที่ -18 วินาทีด้วย
    TAI กับ GPS มี offset คงที่ 19 วินาทีระหว่างกัน

  • อยากรู้ว่าระบบอย่าง Spanner จะเป็นอย่างไรในสถานการณ์แบบนี้
    เป็นเรื่องปวดหัวหรือว่าไม่ได้มีอะไรนัก?

    • เป็นปัญหาใหญ่ วิธีที่ใช้กันบ่อยที่สุดในการรับมือเรียกว่า smearing โดยจะปรับความยาวของแต่ละวินาทีตลอด 24 ชั่วโมงก่อน “leap second”
      ในระบบที่ต้องการการรับประกันลำดับอย่างเข้มงวด วิธีนี้ใช้ได้เพราะอุปกรณ์แต่ละตัวจะยังซิงก์กับนาฬิกากลาง และมีเพียงความยาวของคาบนาฬิกาที่ต่างออกไปเล็กน้อย เท่าที่จำได้มีพูดไว้ในงานวิจัย Spanner ต้นฉบับด้วย
      ระบบที่พบไม่บ่อยบางระบบใช้วินาทีจากออสซิลเลเตอร์แบบโมโนโทนิกและไม่สนใจวินาทีจากการหมุนของโลกเลย แต่ถ้าสุดท้ายต้องแปลงมันกลับเป็นเวลาจริง ความหายนะจะสะสมไปเรื่อยๆ ตามกาลเวลา และโดยทั่วไปก็ไม่ถือว่าเป็นความคิดที่ดี
    • leap second ไม่ได้ถูกเพิ่มตามตารางสม่ำเสมอแบบ leap day แต่เปลี่ยนไปตามการวัดทางกายภาพของโลก
      เพราะแบบนี้ ระบบความเชื่อถือสูงที่มีการจัดการเวลาแบบครอบคลุมก็น่าจะไม่สั่นคลอนมากนักจากการตัดสินใจลักษณะนี้

  • ถ้ามี Temporal API เบราว์เซอร์หรือ Node.js จะจัดการเวลาได้ถูกต้องสำหรับการคำนวณรอบช่วงเวลานั้นไหม? หรือว่าต้องอัปเดตเพื่อไม่ให้การคำนวณพัง?

    • ดูเหมือน Temporal API จะอิงกับ Unix/POSIX timestamp ที่เพิกเฉยต่อ leap second ในเวลา Unix หนึ่งวันมี “วินาที” 86400 เสมอ
      เพราะแบบนั้นจึงคำนวณปฏิทิน UTC ทั้งอดีตและอนาคตได้ง่ายโดยไม่ต้องมีฐานข้อมูล และไม่จำเป็นต้องจัดการเศษวินาทีเสมอไป leap second ถูกจัดการโดยระบบปฏิบัติการด้วยการซ้ำ 1 วินาที ข้าม 1 วินาที หรือปรับความยาวของวินาทีในช่วงเวลาหนึ่งก่อนหรือหลัง leap second
      API วันเวลาโดยมากถูกออกแบบมาเพื่อรองรับการคำนวณปฏิทินและเวลาตามนาฬิกาสำหรับงานเชิงธุรกิจเป็นหลัก ถ้าคุณต้องการ SI second สำหรับงานทางวิทยาศาสตร์ คุณต้องใช้ API และความสามารถแยกต่างหากที่ให้และรับประกันความหมายที่ต้องการลงไปถึงระดับฮาร์ดแวร์
      เช่นเดียวกัน ถ้าต้องการตัวจับเวลาสำหรับฟังก์ชันซอฟต์แวร์อย่าง thread sleep ก็ควรใช้อินเทอร์เฟซเฉพาะอย่างนาฬิกาแบบโมโนโทนิก แม้ leap second จะค่อยๆ หายไป สถานการณ์นี้ก็ไม่ได้เปลี่ยนไปมากนัก ไม่ว่าจะมีหรือไม่มีการปรับ leap second ตัวอย่างเช่น การให้อัลกอริทึม mutex พึ่งพา Unix timestamp นั้นผิดมาตั้งแต่แรกและจะยังคงผิดอยู่ต่อไป

  • ฟังฉันก่อนนะ แค่ติด เครื่องยนต์ไอพ่น ไว้ที่เส้นศูนย์สูตรแล้วหมุน 180 องศา เราก็จะได้หรือเสียเวลา แล้วก็เอาสิ่งนั้นไปต่อเข้ากับปุ่ม snooze ของฉัน

    • ให้ Superman บินรอบโลกเร็วๆ หลายรอบน่าจะง่ายกว่านะ แบบนั้นก็ไม่ต้องกังวลเรื่องบำรุงรักษาเครื่องยนต์
    • จริงๆ แล้วถ้าย้ายมวลน้ำจำนวนมหาศาล ก็อาจสร้างผลที่วัดได้เหมือนกัน เช่น การสูบน้ำจนชั้นหินอุ้มน้ำ California Central Valley ร่อยหรอ
    • ปัญหาคือสังคมอนาคตจะยึดเครื่องยนต์เหล่านั้นไปใช้กับยานสำรวจระหว่างดวงดาว ประเด็นนี้ถูกพูดถึงในชุดนิยายของ Larry Niven
    • บางทีถ้าพวกเรากระโดดพร้อมกันทั้งหมดก็น่าจะพอ ต้องการแค่ 1–2 วินาทีเองไม่ใช่เหรอ?
    • จากการที่ไม่จำเป็นต้องเพิ่ม leap second มาสักพักแล้ว ดูเหมือนว่าวิธีนี้จะได้ผลนะ

  • มีข้อความว่า “ความต่างระหว่าง UTC กับ TAI คือ UTC-TAI = -37s ตั้งแต่ 0:00 UTC ของวันที่ 1 มกราคม 2017 จนกว่าจะมีประกาศเพิ่มเติม”
    นี่หมายความว่านาฬิกาอะตอม ช้ากว่า นาฬิกาสุริยะ 37 วินาทีหรือเปล่า? แล้วก็ไม่เข้าใจว่าทำไมถึงพูดถึงปี 2017

    • จริงๆ แล้วเกือบจะตรงกันข้าม
      หนึ่งวันของ UTC ถูกนิยามให้มี 86400 SI วินาที พอดี แต่วันสุริยะเฉลี่ยจริงยาวกว่านั้นอีกไม่กี่มิลลิวินาที ความต่างนี้ไม่คงที่เพราะความไม่สม่ำเสมอของการหมุนโลก แต่คาดว่าค่าเฉลี่ยจะค่อยๆ เพิ่มขึ้นตามเวลา SI วินาทีถูกนับด้วยนาฬิกาอะตอม ดังนั้น UTC จึงข้ามวันใหม่ทุกๆ 86400 วินาทีของนาฬิกาอะตอม
      ส่วนนาฬิกาสุริยะซึ่งข้ามวันใหม่เมื่อดวงอาทิตย์เฉลี่ยถึงเที่ยง จะข้ามวันใหม่ช้ากว่า UTC อยู่ไม่กี่มิลลิวินาที ดวงอาทิตย์จริงเคลื่อนผ่านท้องฟ้าด้วยความเร็วต่างกันตลอดทั้งปี จึงต้องใช้ดวงอาทิตย์เฉลี่ย
      หากพูดอีกแบบ คือแต่ละช่วงเวลาที่นาฬิกาสุริยะเรียกว่า 86400 วินาทีนั้น จะยาวกว่าตามนาฬิกาอะตอมอยู่ไม่กี่มิลลิวินาที
      เรื่องนี้สะสมทุกวัน จนเมื่อเกือบครบ 1 วินาที ก็จะใส่ leap second เข้าไปใน UTC ทำให้วันนั้นมี 86401 วินาทีแทน 86400 เพราะ UTC ไม่ได้มีไว้แค่นับเวลาอะตอม แต่ยังต้องซิงก์กับดวงอาทิตย์ด้วย เนื่องจากกิจกรรมของมนุษย์จำนวนมากผูกกับตำแหน่งของดวงอาทิตย์บนท้องฟ้า
      มนุษย์นิยามคำว่า “ซิงก์กับดวงอาทิตย์” ว่าหมายถึง “อยู่ภายใน 1 วินาทีของดวงอาทิตย์เฉลี่ย” กล่าวคือ เราต้องการให้เที่ยง UTC อยู่ภายใน 1 วินาทีของเที่ยงสุริยะเฉลี่ยที่เส้นเมริเดียนหลัก
      ดังนั้น 37 วินาทีจึงหมายถึงว่าถ้าไม่ใช้ leap second เที่ยงสุริยะเฉลี่ยจะช้ากว่าเที่ยง UTC ไปเท่าใด เมื่อเป็นเที่ยง UTC ดวงอาทิตย์เฉลี่ยก็ยังขาดอีก 37 วินาทีกว่าจะผ่านเส้นเมริเดียนหลักบนท้องฟ้า
    • ตาม Wikipedia ธันวาคม 2016 คือครั้งล่าสุดที่มีการแทรก leap second: https://en.wikipedia.org/wiki/Leap_second
    • ที่พูดถึงปี 2017 ก็เพราะนั่นเป็นครั้งล่าสุดที่ offset นี้เปลี่ยน ดังนั้นค่า -37 วินาทีจึงมีผลต่อเนื่องมาตั้งแต่นั้น