`Australia/Lord_Howe` คือเขตเวลาที่ประหลาดที่สุด

 (ssoready.com)
2 คะแนน โดย GN⁺ 2024-10-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เขตเวลานั้นซับซ้อน แต่เพราะคอมพิวเตอร์ต้องนำไปใช้งาน ความประหลาดจึงอยู่ภายในขอบเขตที่มีจำกัด
    • Asia/Kathmandu มีออฟเซ็ตจาก UTC ที่แปลก
    • Africa/Casablanca เข้ากับโมเดลเขตเวลาได้ไม่ดีนัก จึงต้องฮาร์ดโค้ดไว้
    • America/Nuuk เริ่มใช้เวลาออมแสงจาก -01:00
    • Africa/Cairo และ America/Santiago เริ่มใช้เวลาออมแสงตอน 24:00 (ไม่ใช่ 0:00)
    • Australia/Lord_Howe มีกฎเวลาออมแสงที่ประหลาดที่สุด

PGXIIREAM: สมเด็จพระสันตะปาปาเกรกอรีที่ 13 ปกครองทุกสิ่ง

  • โลกส่วนใหญ่ใช้ระบบเวลาที่อิงกับปฏิทินเกรกอเรียน
  • ปฏิทินเกรกอเรียนมีประโยชน์มากในการทำให้ตำแหน่งของดวงอาทิตย์สอดคล้องอย่างสม่ำเสมอตลอดปี
  • UTC คือการทำให้ปฏิทินเกรกอเรียนเป็นมาตรฐานสมัยใหม่ และทั้งโลกใช้มันเป็นเกณฑ์ในการตั้งเวลา

อธิกวินาทีไม่สำคัญ

  • การหมุนของโลกกำลังช้าลง จึงมีการเพิ่มอธิกวินาทีเพื่อชดเชย
  • อธิกวินาทีสามารถมองข้ามได้ เพราะภาษาโปรแกรมไม่ได้แทนค่า 61 วินาที
  • ผู้ให้บริการคลาวด์แก้ปัญหานี้ด้วยการทำให้นาฬิกาเดินช้าลงในช่วงอธิกวินาที

เขตเวลาที่แปลกประหลาด

Asia/Kathmandu มีออฟเซ็ตที่แปลก

  • เนปาลเร็วกว่า UTC อยู่ 5 ชั่วโมง 45 นาที
  • คอมพิวเตอร์สามารถรู้ข้อมูลนี้ได้ผ่านฐานข้อมูลเขตเวลา IANA

สตริงอย่าง PDT หรือ CET ไม่มีความหมาย

  • ตัวระบุเขตเวลาอาจกำกวม และหลายเขตเวลาก็ใช้ตัวระบุเดียวกัน

เขตเวลาที่มีเวลาออมแสงแสดงอย่างไร?

  • กฎการสลับเวลาออมแสงมีความซับซ้อน และคอมพิวเตอร์จะคำนวณเวลาท้องถิ่นจากกฎเหล่านี้

Africa/Casablanca และ Asia/Gaza เดินตามดวงจันทร์ แต่เขตเวลาเดินตามดวงอาทิตย์

  • โมร็อกโกและกาซาปรับเวลาออมแสงตามรอมฎอน ซึ่งต้องฮาร์ดโค้ดไว้

America/Nuuk เปลี่ยนเป็นเวลาออมแสงตอน -1 นาฬิกา

  • กรีนแลนด์เริ่มใช้เวลาออมแสงพร้อมกับยุโรป แต่ในเวลาท้องถิ่นจะเริ่มตอน -1 นาฬิกา

America/Santiago และ Africa/Cairo เปลี่ยนตอน 24:00

  • เขตเวลาเหล่านี้สลับเวลาออมแสงตอน 24:00 ซึ่งหมายถึงการข้ามไปวันถัดไป

Australia/Lord_Howe มีการเปลี่ยนเวลาออมแสงที่ประหลาดที่สุด

  • เกาะลอร์ดฮาวมีการเปลี่ยนเวลาออมแสงครั้งละ 30 นาที

สรุปของ GN⁺

  • เขตเวลานั้นซับซ้อน แต่เพราะคอมพิวเตอร์ต้องนำไปใช้งาน ความประหลาดจึงอยู่ภายในขอบเขตที่มีจำกัด
  • Australia/Lord_Howe เป็นเขตเวลาที่มีเอกลักษณ์ที่สุด เพราะเปลี่ยนเวลาออมแสงครั้งละ 30 นาที
  • บทความนี้มีประโยชน์ในการทำความเข้าใจความซับซ้อนของเขตเวลา และอาจน่าสนใจสำหรับโปรแกรมเมอร์
  • โปรเจ็กต์ที่มีฟังก์ชันคล้ายกันคือ tzdb

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

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

 
GN⁺ 2024-10-31
ความคิดเห็นบน Hacker News

  • ส่วนที่น่าสนุกที่สุดในฐานข้อมูล tz คือมี ค่าประมาณเวลาของบิกแบง อยู่ด้วย และถูกกำหนดไว้ไม่ให้คำนวณการเปลี่ยนเขตเวลาที่เกิดขึ้นก่อนบิกแบง
    ข้อความคอมมิตของ https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... ก็มีใจความว่า “อย่าสร้าง timestamp ก่อนบิกแบง เพราะน่าสงสัยทางฟิสิกส์” และไม่นานหลังจากนั้นก็มีคอมมิตแยกที่ห้าม leap second ก่อนบิกแบงด้วย

    • เมื่อก่อนเคยมีหน้า manual ยาว ๆ ของ Linux/Unix date ที่พูดถึงความหมายของวันที่ในอดีต
      มีตัวอย่างราวศตวรรษที่ 15 พร้อมเรื่องเล่าว่ากษัตริย์องค์หนึ่งชอบสัปดาห์/เดือนหนึ่งเป็นพิเศษจึงสั่งให้ทำซ้ำ หรือกษัตริย์อีกองค์เกลียดสัปดาห์หนึ่งจึงลบออกจากปฏิทิน เป็นบทอ่านที่เปิดหูเปิดตามาก แต่ตอนนี้หาไม่เจอแล้ว
    • ดูเป็นการตัดสินใจที่ค่อนข้างใช้งานได้จริง เป็นวิธีที่ดีในการกันข้อถกเถียงไร้สาระแบบ เถียงกันว่าเทวดายืนบนปลายเข็มได้กี่องค์ ระหว่างผู้ร่วมพัฒนาไว้ล่วงหน้า
      พูดอีกอย่างคือข้อสรุปว่า “ช่วงเวลาก่อนบิกแบงอยู่นอกขอบเขตของไลบรารีนี้ ดังนั้นถ้าอัลกอริทึมใดให้ค่าผิดเฉพาะก่อนบิกแบง อัลกอริทึมนั้นก็ยอมรับได้และไม่จำเป็นต้องปรับปรุง/เปลี่ยนใหม่”
    • เป็นส่วนที่เจ๋งจริง ๆ แต่แยกอีกเรื่องหนึ่ง ผมค่อนข้างกังขากับความพยายามของ tzdb ที่จะครอบคลุมไปถึง ก่อน Unix epoch
      ประโยชน์เมื่อเทียบกับบั๊กในส่วนนั้นดูไม่มากนัก และความซับซ้อนยุ่งเหยิงส่วนใหญ่ของ tzdb ก็อยู่ใน zic บางครั้งก็รู้สึกว่าคงดีกว่าถ้า zic ไม่ได้เป็นผลลัพธ์ที่คนอื่นพึ่งพาได้
    • เป็น easter egg ที่น่าสนุกของฐานข้อมูล TZ เพิ่งเคยได้ยินครั้งแรก แต่ก็สงสัยว่าจะมีโอกาสต้องคำนวณข้อมูลเขตเวลาที่เก่าแก่ขนาดนั้นสักแค่ไหน
      หวังว่าเขตเวลาจะหายไปก่อนที่ทฤษฎีเรื่องเขตเวลาจะล้าสมัย

  • ผมว่าเขตเวลาที่แปลกที่สุดคือ Africa/Addis_Ababa เพราะจริง ๆ แล้ว คนท้องถิ่นในเอธิโอเปีย ไม่ได้ใช้วิธีนั้น
    ในท้องถิ่นจะเลื่อนเวลาไป 6 ชั่วโมง โดยรอบ AM เริ่มตอนรุ่งเช้า คือ 6 โมงเช้า และรอบ PM เริ่มตอนพลบค่ำ คือ 6 โมงเย็น
    https://en.wikipedia.org/wiki/Time_in_Ethiopia

    • เป็นวิธีที่พบได้ทั่วไปทั่ว แอฟริกาตะวันออก รวมถึงเคนยา กลางคืนสิ้นสุดตอน 6 โมงเช้า และ 7 โมงเช้าคือชั่วโมงแรกของวัน เรียกว่า saa moja
      ในทำนองเดียวกัน วันสิ้นสุดตอน 6 โมงเย็น หรือ thenashara ถ้ามองตามสัญชาตญาณก็สมเหตุสมผลกว่านาฬิกาแบบโลกภาษาอังกฤษมาก และเพราะมันฝังอยู่ในภาษา ความสับสนเรื่องเวลาก็พบได้น้อย
    • การนับเวลาในเอธิโอเปียโดยรวมค่อนข้างพิเศษ
      https://en.wikipedia.org/wiki/Ethiopian_calendar
      ปฏิทินเอธิโอเปีย ประกอบด้วย 12 เดือนที่มีเดือนละ 30 วัน และวันอธิกสุรทิน 5 หรือ 6 วันที่ประกอบกันเป็นเดือนที่ 13
    • คล้ายกับวิธีที่ชาวโรมันเข้าใจเวลาอย่างมาก สงสัยว่าเป็นร่องรอยเก่าแก่จากสมัยที่แอฟริกาเหนือเป็นหลายมณฑลหรือเปล่า
      https://en.wikipedia.org/wiki/Roman_timekeeping
    • ถ้าเป็นประเทศใกล้เส้นศูนย์สูตร วิธีนิยามวงรอบของวันแบบนั้นก็ไม่ได้ไร้เหตุผลนัก
    • ญี่ปุ่นก็ใช้วิธีคล้ายกันในบริบทอย่างสถานที่ที่ปิดหลังเที่ยงคืน: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
      โลกภาษาอังกฤษก็เคยเปลี่ยนปีใหม่ในวันที่ 25 มีนาคม: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
      ทั้งสองอย่างในทางเทคนิคไม่ใช่สิ่งที่ tzdb จัดการได้ tzdb จัดการ civil time ไม่ได้จัดการไปถึงปฏิทินหรือระบบคำนวณแบบอื่น

  • ความแปลกของ Asia/Jerusalem เป็นเพราะ เวลาออมแสง พัวพันกับประเด็นการแยกรัฐกับศาสนาอย่างมาก คนเคร่งศาสนาต้องการให้วันทำงานสะดวกสอดคล้องกับเทศกาลที่เริ่มตอนพระอาทิตย์ตก
    ดังนั้นเป็นเวลาหลายทศวรรษจนถึงช่วงกลางทศวรรษ 2000 เวลาออมแสงจึงเป็นผลจากการเจรจาประจำปีระหว่างพรรคศาสนากับพรรคฆราวาส และมักตัดสินใจกันก่อนวันเปลี่ยนเวลาไม่นาน ทำให้เกิดปัญหาบ่อยครั้ง
    แม้ตอนนี้ก็ยังมีข้อยกเว้นไม่ให้เวลาออมแสงสิ้นสุดในวัน Rosh HaShanah อยู่ จึงดูเหมือนทำให้กฎในอนาคตซับซ้อน

    • ข้อดีของเวลาออมแสงมีจำกัด และโดยเฉพาะถ้าเป็นประเทศที่อยู่ค่อนข้างใต้ ก็สงสัยว่าทำไมไม่ยกเลิกไปเสียทั้งหมด
      ถ้า EU ยกเลิกสำเร็จในที่สุด ก็อาจตามไปด้วยก็ได้
    • เป็นเพราะเทศกาลปัสกา มื้อฉลองใหญ่ที่เรียกว่า Seder ดำเนินต่อไปจนเลยเที่ยงคืน และเป็นงานสำคัญมากสำหรับเด็ก ๆ ด้วย
      จึงไม่อยากให้เวลาออมแสงทำให้งานที่เลิกดึกอยู่แล้วดึกยิ่งขึ้น อีกทั้งในวันถือศีลอด Yom Kippur ก็อยากให้การถือศีลอดจบเร็วขึ้น 1 ชั่วโมง การพยายามปรับให้ตรงกับวันเหล่านี้ทำให้ช่วงเวลาออมแสงสั้นเกินไป จึงต้องมีการเจรจา
    • ไม่มีข้อยกเว้นแล้ว IDT ถูกขยายในปี 2013 ให้ใช้จนถึงวันอาทิตย์สุดท้ายของเดือนตุลาคม

  • คำกล่าวที่ว่า “ภาษาโปรแกรมไม่สามารถแทนนาทีที่มี 61 วินาทีได้” นั้นไม่จริง มีคนบอกไปแล้วว่า Raku รองรับวินาทีกระโดด และเรื่องนั้นอาจเป็นความผิดของผมส่วนหนึ่ง
    เพราะ DateTime.pm ซึ่งเป็นไลบรารีวันที่/เวลายอดนิยมที่สุดของ Perl 5 รองรับวินาทีกระโดด และผมเป็นคนสร้าง DateTime.pm พร้อมทั้ง implement การรองรับนั้น
    มองย้อนกลับไป แทบจะแน่นอนว่าเป็นความผิดพลาด มีคนสนใจ วินาทีกระโดด น้อยมาก และมีแต่สร้างความสับสนแปลก ๆ อย่าง “ทำไมบางครั้งการบวก 60 วินาทีถึงไม่เหมือนกับการบวก 1 นาที?”
    โดยเฉพาะเพราะพยายามตรวจสอบว่า second => 60 ถูกต้องหรือไม่ โค้ดจึงซับซ้อนขึ้นมาก constructor รับองค์ประกอบของเวลาและ timezone ใด ๆ ดังนั้นหากจะตรวจตารางวินาทีกระโดดก็ต้องแปลงเป็น UTC ก่อน แต่การแปลงนั้นเองก็ดันไปพัวพันกับค่าที่รวมวินาทีกระโดดด้วยเหตุผลทางประวัติศาสตร์
    กลายเป็นความวุ่นวายขนาดใหญ่เพื่อประโยชน์เพียงเล็กน้อย และดูเหมือนว่าไลบรารีวันที่/เวลามาตรฐานของ Raku ก็ยืมมาจาก DateTime.pm ของ Perl 5 อยู่มาก จึงคิดว่าน่าจะสืบทอดการตัดสินใจออกแบบที่ไม่ดีแบบเดียวกันมาบางส่วน

    • ก็ดีที่ได้ implement แบบนั้น และภายหลังยังได้ย้อนมองหาทางออกที่สง่างามกว่า
      ตอนแรกสงสัยว่ากระบวนการคิดเป็นอย่างไร หมกมุ่นกับปัญหามากเกินไปหรือเปล่า? เวลาอยู่ใกล้ปัญหาเกินไปและจดจ่อกับมันนาน ๆ ความสนุกของการแก้ก่อนที่มันจะพังก็มักนำหน้า จนเกิดเรื่องแบบนี้ได้
    • ใน Raku มีคลาส Instant
      นิยามประมาณว่า “Instant คือชั่วขณะหนึ่งที่วัดเป็นวินาทีอะตอมและส่วนเศษของมัน และไม่ได้ผูกกับหรือ aware ต่อ epoch ใด ๆ”

  • เมื่อต้นปีนี้ ผมต้องเขียนฟังก์ชันที่หาเวลาท้องถิ่นปัจจุบันเมื่อให้ที่อยู่ในสหรัฐฯ มา วิธีแบบซื่อ ๆ คือ map รัฐเข้ากับ timezone แบบ static แต่มีข้อยกเว้นอยู่พอสมควรที่ทำให้ทำแบบนั้นไม่ได้
    ในแอปพลิเคชันนั้น ต้นทุนและความเร็วสำคัญ จึงซื้อ CSV ราคาไม่กี่ดอลลาร์ที่ map ZIP code ทั้งหมดของสหรัฐฯ เข้ากับ UTC offset และสถานะว่าปฏิบัติตาม daylight saving time หรือไม่ ฯลฯ
    pytz รับชื่อ timezone ของ IANA ดังนั้นสุดท้ายจึงต้อง map ข้อมูล offset และ daylight saving time ไปยัง timezone เฉพาะด้วยมือ และเพราะดินแดนโพ้นทะเลกับฐานทัพของสหรัฐฯ จึงต้องใช้ semantics แปลก ๆ อย่าง timezone Etc ด้วย
    [1] https://en.wikipedia.org/wiki/Tz_database#Area

    • ระดับรัฐมี resolution ผิดไปโดยสิ้นเชิง timezone ของสหรัฐฯ เดินตามเส้นเขต เคาน์ตี และเขตสงวนของชนพื้นเมือง
      ZIP code ก็น่าจะพอได้ แต่ต้องระวัง ถ้าจำนวนที่อยู่ไม่มากเกินไป วิธีที่ robust กว่าคือทำ reverse geocoding แล้วใช้ไลบรารีที่ดึง IANA identifier จากรูปทรงเส้นเขต timezone
      https://github.com/RomanIakovlev/timeshape ดูแลโดยอดีตเพื่อนร่วมงานของผม และเราสามารถเปิดซอร์สบางส่วนของงานที่เคยทำภายในได้
    • เมื่อปี 1985 ตอนเป็นวิศวกรหนุ่มเพิ่งจบมหาวิทยาลัย ผมได้รับมอบหมายให้รวมข้อมูล telemetry ที่บันทึกลงเทปแม่เหล็กจากไซต์เรดาร์หลายแห่งในสหรัฐฯ
      ระบบหนึ่งหรือสองระบบประทับเวลาข้อมูลเป็นเวลาท้องถิ่น ส่วนที่เหลือใช้ UTC ผมซื้อ Farmers' Almanac เก่า ๆ มาเพื่อจะทำอัลกอริทึมจัดการ daylight saving time แต่พออ่านกฎแล้วก็สิ้นหวัง
      ในปฏิทินมีกฎตามชื่อสำหรับการเปลี่ยนเวลา แต่มีเชิงอรรถว่ามันถูกปรับมาแทบทุกปีเพราะการแทรกแซงของสภาคองเกรส และในอนาคตก็คงเป็นแบบนั้นต่อไป ผมบอกหัวหน้าว่า “ถ้าผมเขียนอัลกอริทึมทำนายการลงมติในอนาคตของสภาคองเกรสได้ ผมคงเป็นมหาเศรษฐีและลาออกจากงานวิศวกรนี้ไปแล้ว”
      สุดท้ายผมคิดว่าได้โค้ดการเปลี่ยนเวลาล่าสุดที่ทราบ และกฎตามชื่อสำหรับอนาคตเข้าไป ตอนนั้นยังเป็นยุคก่อนที่ทุกคนจะเชื่อมต่อเครือข่าย และโค้ดรันบนคอมพิวเตอร์ standalone อย่าง VAX จึงแทบไม่มีวิธีอื่น
      งานรวมแหล่งข้อมูลติดตามสามแหล่ง ซึ่งแต่ละแหล่งมีสถานะความถูกต้องและคุณภาพการวัดที่ลดลงของตัวเอง ก็เป็นฝันร้ายเหมือนกัน แต่ก็ยังง่ายกว่าการทำนายการกระทำในอนาคตของสภาคองเกรส
    • วิธีที่ดีคือ map ZIP code เข้ากับ timezone ที่มีชื่อ เช่น US/Eastern จากนั้นถ้าต้องการ UTC offset ก็ใช้ pytz apply timezone กับวันที่นั้นเพื่อให้ได้ offset
      timezone ที่มีชื่อพิเศษตรงที่คงที่ ส่วน timezone แบบ UTC offset อย่าง -05:00 หรือคำย่ออย่าง EST ไม่คงที่ตามเวลาสำหรับตำแหน่งหนึ่ง ๆ เพราะ daylight saving time
      ถ้าถาม timezone จากใครแล้วให้เลือกเป็น offset หรือคำย่อ ทุกคนจะสับสน
    • เมื่อต้นปีนี้ผมทำงานคล้าย ๆ กัน โดยใช้บริการ geolocation แปลงที่อยู่เป็นละติจูด/ลองจิจูด แล้วค่อยหา timezone จากละติจูด/ลองจิจูดอีกที มีทางลัดสำหรับรัฐที่มี timezone เดียว
      สำหรับการแปลงละติจูด/ลองจิจูด → timezone ใช้ไลบรารี Python นี้: https://github.com/jannikmi/timezonefinder
      แหล่งข้อมูลก็ดูเหมือนเป็นแหล่งที่มีคุณภาพค่อนข้างสูง: https://github.com/evansiroky/timezone-boundary-builder/rele...
    • ต้องระวัง identifier Etc มาก ๆ โดยเฉพาะถ้าตั้งใจจะเปิดเผย identifier ทั้งหมดให้ผู้ใช้เห็นโดยตรง
      ในไฟล์นั้นมีคอมเมนต์ว่า “POSIX ถือว่าทางตะวันตกของกรีนิชเป็นค่าบวก แต่หลายคนคาดว่าทางตะวันออกของกรีนิชเป็นค่าบวก ตัวอย่างเช่น TZ='Etc/GMT+4' ใช้คำย่อ -04 และหมายถึงช้ากว่า UT 4 ชั่วโมง คือทางตะวันตกของกรีนิช แต่หลายคนคาดว่าจะเป็นทางตะวันออกที่เร็วกว่า UT 4 ชั่วโมง”

  • เขตเวลาของปาเลสไตน์ก็ค่อนข้างแปลกเหมือนกัน
    https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
    มีระบบเวลาออมแสง แต่วันที่ไม่ได้กำหนดตายตัว รัฐบาลจะประกาศเวลาเริ่มและสิ้นสุดทุกปี บางครั้งประกาศล่วงหน้าไม่ถึงสัปดาห์ จึงเลี่ยงไม่ได้ที่จะเกิดปัญหาน่าสนใจสารพัด

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

  • ผมคิดว่าการเรียกระบบเวลาออมแสงที่ต่างกัน 30 นาที ไม่ใช่ 1 ชั่วโมง ว่าเป็น “เขตเวลาที่แปลกที่สุด” นั้นตั้งเกณฑ์ต่ำเกินไป
    แทบทุกอย่างอื่นดูแปลกกว่า Antarctica/Troll ฟังดูแปลกกว่าอย่างชัดเจน และเขตเวลาของโมร็อกโกกับกาซาก็มีกฎอย่างน้อยคนละแบบ เพราะแปลด้วยระบบเดิมไม่ได้ด้วยซ้ำ เขตเวลาที่เปลี่ยนในวันก่อนหน้าวันที่กำหนด ซึ่งติดอยู่ในรายการแบนของ Apple ก็แปลกพอจะทำให้บางอย่างพังได้
    เรื่องวินาทีกระโดดผมเห็นด้วย มันแทบจะเป็นความรู้รอบตัวมากกว่าจะเป็นความรู้ที่มีประโยชน์ซึ่งโปรแกรมเมอร์ควรรู้ คอมพิวเตอร์จัดการวินาทีกระโดดด้วยการ smear และไม่รู้ด้วยซ้ำว่ามันเกิดขึ้นเมื่อไร ลืมมันไปโดยสิ้นเชิงก็ได้
    อย่างไรก็ตาม เคยมีช่วงที่ประเทศต่าง ๆ เปลี่ยนจากวิธีที่ไม่สนใจวินาทีกระโดดมาเป็นวิธีที่คำนึงถึงมัน ดังนั้นการเปลี่ยนจาก GMT+x เป็น UTC+x ในออสเตรเลียเมื่อหลายสิบปีก่อน จึงเป็นการเปลี่ยนผ่านจากการไม่สนใจวินาทีกระโดดไปสู่การนับรวมมันด้วย บางทีการที่ข้อเท็จจริงนี้ถูกมองข้ามแทบจะทั่วไปหมดอาจเป็นเรื่องดีกว่าก็ได้

    • โดยรวมเห็นด้วยว่าวินาทีกระโดดเป็นความรู้รอบตัว
      แต่ก็อดขำไม่ได้เสมอเมื่อองค์กรขนาดใหญ่บางแห่งพูดว่า “เซิร์ฟเวอร์ของเรามีความแม่นยำด้านเวลาต่ำกว่าระดับมิลลิวินาที ด้วยการซิงก์ GPS และการ์ดนาฬิกาอะตอมรูบิเดียมแบบ PCIe ที่พัฒนาขึ้นเอง” แต่ในขณะเดียวกันก็พูดว่า “วินาทีกระโดดจะถูก smear ตลอดทั้งวัน ดังนั้นต่อให้เวลาเซิร์ฟเวอร์คลาดเคลื่อนจริง ±0.5 วินาทีก็ไม่เป็นไร”
      [1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
      [2] https://engineering.fb.com/2020/03/18/production-engineering...
    • วันที่ของรอมฎอนไม่ใช่ค่าที่รู้กันแน่ชัด เพราะอิงกับว่า สามารถมองเห็นดวงจันทร์ได้จริงหรือไม่ ในพื้นที่ใดพื้นที่หนึ่งบนโลก
      เช่น ถ้าท้องฟ้ามีเมฆมาก ก็จะมองไม่เห็นไม่ว่าดวงจันทร์จะอยู่ตรงไหนก็ตาม เรื่องนี้ทำให้เกิดปัญหาเมื่อต้องนำปฏิทินไปใช้ในการบริหารประเทศ
      หลายประเทศที่ใช้ปฏิทินอิสลามอย่างเป็นทางการ ใช้วันที่โดยประมาณที่คำนวณล่วงหน้าจากการคาดการณ์การมองเห็น ณ ตำแหน่งเฉพาะ ดังนั้นปฏิทินอิสลามจริง ๆ แล้วไม่ใช่แบบเดียว แต่ใกล้เคียงกับการมีสองแบบ คือปฏิทินอิสลามแบบอิงการสังเกตการณ์และปฏิทินแบบคาดการณ์ และทั้งสองแบบก็ขึ้นอยู่กับตำแหน่งที่มีการสังเกตการณ์จริงหรือที่คาดการณ์ไว้
      ไม่รู้ว่าโมร็อกโกหรือกาซาทำอย่างไร
    • Antarctica/Troll ไม่ได้แปลกขนาดนั้น ในทางปฏิบัติคือใช้เวลาของเคปทาวน์ในช่วงฤดูร้อนสั้น ๆ และใช้เวลาของนอร์เวย์ในช่วงที่เหลือ
      เพียงแต่ว่าเวลานอร์เวย์ดันใช้เวลาออมแสงด้วย
    • วินาทีกระโดดโดยรวมเป็นความรู้รอบตัว แต่ในแอปพลิเคชันที่หลายฝ่ายต้องตกลงกันอย่างแม่นยำเรื่องลำดับเวลา มันจะสำคัญอย่างยิ่ง ตัวอย่างเด่นคือ ธุรกรรมทางการเงิน
      ตลาดจำนวนมากปิดทำการในช่วงวินาทีกระโดด และธนาคารจำนวนมากยังคงหยุดธุรกรรมทั้งหมดเมื่อมีการเปลี่ยนเวลาท้องถิ่น เพื่อลดความเสี่ยงของข้อผิดพลาด
      แม้แต่ในแอปพลิเคชันที่ไม่ค่อยใส่ใจเรื่องนี้ ก็เคยมีบั๊กเกี่ยวกับวินาทีกระโดดมากจนน่าประหลาดใจ และมีเหตุผลที่ดีที่ CGPM ตัดสินใจยกเลิกวินาทีกระโดด
      https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
    • ผมเข้ามาเพื่อหา Troll นี่แหละ เท่าที่ผมรู้ ที่นี่เป็นที่เดียวที่มี เวลาออมแสงฤดูหนาว และยังได้คะแนนเพิ่มเพราะชื่อด้วย

  • เป็นบทความยอดเยี่ยมที่ว่าด้วยกายกรรมของซอฟต์แวร์เขตเวลา ยืดหยุ่นมากจริง ๆ
    ถ้าทั้งหมดเป็นออฟเซ็ตแบบจำกัดที่ทำงานอัตโนมัติ ก็ไม่มีเหตุผลที่นโยบายเวลาออมแสงจะต้องยึดกับการปรับ 60 นาทีเสมอไป
    เป็นไปได้ไหมที่บางประเทศจะเลือกใช้ ออฟเซ็ตที่เปลี่ยนแปลงอย่างต่อเนื่อง ตลอดทั้งปี? ตารางค้นหาออฟเซ็ตคงจะยาวขึ้นมาก แต่แบบนี้อาจ “แก้” เรื่องเวลาออมแสงได้ เพราะมันปรับทีละนิดไปเรื่อย ๆ จึงน่าจะไม่ทันสังเกตเหมือนวินาทีกระโดด
    คนที่พึ่งพานาฬิกาอนาล็อกอาจไม่ต้องปรับไปในทิศทางเดิมทุกครั้งอีกต่อไป

    • ตั้งแต่นาฬิกาของอุปกรณ์อิเล็กทรอนิกส์ซิงก์เวลากันเป็นเรื่องปกติ ผมก็เสนอแทบทุกคนที่ยอมฟังว่า ให้ปรับไปข้างหน้าเดือนละ 10 นาทีในวันอาทิตย์แรกของทุกเดือนเป็นเวลา 6 เดือน แล้วปรับถอยหลังเดือนละ 10 นาทีในวันอาทิตย์แรกของทุกเดือนสำหรับอีก 6 เดือนที่เหลือ
      การเปลี่ยนแปลง 10 นาที เดือนละครั้งปรับตัวได้ง่ายกว่ามาก แทบไม่รู้สึก และถึงพลาดก็ไม่เป็นเรื่องใหญ่เท่ากับเวลาคลาดไป 1 ชั่วโมง
    • ถ้าไปตามทางนั้น ข้อสรุปเชิงตรรกะก็คือยกเลิกแนวคิดเรื่องเขตเวลาไปเลย แล้วกลับไปใช้ เวลาสุริยคติท้องถิ่น
    • คุณกำลังมองข้ามวิธีที่ง่ายที่สุดในการ “แก้” เวลาออมแสง
      ก็เลิกใช้เวลาออมแสงไปสิ ส่วนตัวผมชอบ เวลามาตรฐานถาวร มากกว่าเวลาออมแสงถาวร แต่ตราบใดที่หยุดการปรับนาฬิกาปีละสองครั้งได้ ผมก็ยอมรับได้
    • อินเดียใช้ UTC+5:30 และไม่มีเวลาออมแสง จึงน่าสนใจเวลาโต้ตอบกับโลก
      แน่นอนว่าจีนก็เป็นกรณีที่รู้กันดีว่า กว้างขนาดนั้นแต่มีเขตเวลาเดียว จึงสร้างสถานการณ์ที่น่าสนใจทั้งภายในและภายนอกประเทศ
    • ในทางทฤษฎีสามารถแสดงด้วย tzdb ได้ แน่นอนว่ามันจะก่อปัญหา
      สมมติฐานสำคัญมากที่ไม่ได้ปรากฏชัดในรูปแบบข้อมูล TZif คือ เมื่อแปลงจากเวลาท้องถิ่นเป็นเวลา UTC จะมีความเป็นไปได้มากที่สุดแค่สองแบบ
      ซอฟต์แวร์จำนวนมากอาศัยสมมติฐานนี้ เช่น java.time.LocalDateTime มี withLaterOffsetAtOverlap(): https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
      นี่ถือโดยนัยว่าเมื่อความหมายของเวลา 2:30 น. คลุมเครือ คำตอบที่เป็นไปได้มีเพียงสองแบบ คือก่อนและหลังเวลาออมแสง หากเขตเวลาใดหมุนนาฬิกาถอยหลังครั้งหนึ่งตอน 2:00 แล้วถอยหลังอีกครั้งตอน 2:15 จนทำให้มีคำตอบสามแบบขึ้นไป หลายสิ่งจะไม่สามารถแทนค่านั้นได้

  • สิ่งที่ผมชอบเกี่ยวกับฐานข้อมูล tz คือ ในเชิงเทคนิคมันคือ diff ของ diff
    มันเก็บว่าความแตกต่างระหว่างแต่ละเขตเวลากับ UTC เปลี่ยนไปอย่างไรในประวัติศาสตร์ จึงมองได้ว่าเป็น diff^2 แต่ฐานข้อมูล tz ก็ได้รับการอัปเดตด้วย ดังนั้นคอมมิตเหล่านั้นคือ diff ของ diff ของ diff หรือ diff^3
    ยังไปต่อได้อีก มีบันทึกการเปลี่ยนแปลง และบันทึกนั้นถูกเก็บใน git ดังนั้นคอมมิตต่อบันทึกการเปลี่ยนแปลงของ tz คือการเปลี่ยนแปลงต่อรายการเปลี่ยนแปลงของรายการเปลี่ยนแปลงของรายการเปลี่ยนแปลงเทียบกับ UTC หรือ diff^4

    • คุณลืมไปว่า UTC และในความหมายที่กว้างกว่านั้น การวัดเวลาเองก็เป็น diff ด้วย
    • diff ของ diff ก็เป็นแค่ diff สองตัว ไม่ใช่ผลคูณของ diff

  • ผมคิดว่ากรอบคิดสำคัญคือ วันที่/เวลาเกือบทั้งหมดจริง ๆ แล้วคือ ชุดกฎการแมตช์ที่กำลังถูกเฝ้าดู
    เราเดาได้ว่าจะใช้เวลากี่วินาทีก่อนที่การแมตช์จะถูกทริกเกอร์ แต่ไม่มีทางมั่นใจเต็มที่จนกว่าจะเกิดขึ้นจริง และในบางกรณีอาจไม่เกิดขึ้นอย่างถูกต้องแม่นยำเลยก็ได้
    ครึ่งถัดไปคือการแปลงการคาดเดาแบบเดลตาว่า “น่าจะเกิดขึ้นในอีก X วินาทีจากตอนนี้” กลับไปเป็น “ตอนนั้นนาฬิกาในเขตเวลาของคุณน่าจะแสดงค่า Y”
    ต้องไม่ลืมติดตามอยู่เสมอว่าเขตเวลาใดเป็นตัวควบคุมอีเวนต์ และมันถูกแสดงผลในเขตเวลาใด
    [1] ค่าประมาณ UTC อาจคลาดไปข้างหน้าหรือข้างหลังเท่ากับวินาทีกระโดดได้ TAI ปลอดภัยกว่า แต่ก็อาจเปลี่ยนได้หากมีใครค้นพบบางอย่างใหม่ ๆ ที่น่าสนใจซึ่งเปลี่ยนพฤติกรรมของอะตอมซีเซียม
    [0] ตัวอย่างเช่น ประเทศอาจหายไปจนไม่มีเขตเวลานั้นแล้วก็ได้ หรือเข็มนาฬิกาอาจกระโดดจาก 1:00 ไปเป็น 2:00 ทำให้ช่วง 1 ชั่วโมงที่หายไปนั้นส่งผลให้ช่วง 1:30–2:00 ไม่ได้เกิดขึ้นอย่างถูกต้องแม่นยำ