ฐานข้อมูลเขตเวลา IANA (tz): คืออะไรและทำไมถึงสำคัญ

สิ่งที่ IANA Time Zone Database จริงๆ แล้วคืออะไร

หากคุณเคยทำงานกับวันที่และเวลาในซอฟต์แวร์ คุณต้องพึ่งพา IANA Time Zone Database ไม่ว่าคุณจะรู้ตัวหรือไม่ก็ตาม ฐานข้อมูลนี้มีชื่อเรียกหลายชื่อ — tz database, tzdata, Olson database หรือ zoneinfo — แต่ทั้งหมดหมายถึงสิ่งเดียวกัน: แคตตาล็อกที่ทำงานร่วมกันและเผยแพร่ฟรีของเขตเวลาทั่วโลกและกฎที่ควบคุมเขตเวลาเหล่านั้น

คำว่า "แคตตาล็อก" ดูจะน้อยเกินไป ฐานข้อมูลนี้ไม่เพียงแต่แสดงว่ารigion ใดอยู่ที่ offset UTC เท่าใด แต่มันบันทึก ประวัติศาสตร์ที่สมบูรณ์ ของการวัดเวลาทางพลเรือนสำหรับแต่ละภูมิภาค — ทุกการเปลี่ยนแปลง offset, ทุกการเปลี่ยนเวลาออมแสง, ทุกการปรับนาฬิกาในช่วงสงคราม, และทุกกฎอนาคตที่กำหนดไว้ — ย้อนกลับไปในหลายกรณีถึงกลางศตวรรษที่ 19 เมื่อเวลามาตรฐานท้องถิ่นถูกแทนที่ด้วยเขตเวลาที่เป็นมาตรฐาน เมื่อแอปปฏิทินของคุณแสดงอย่างถูกต้องว่าการประชุมในปี 1985 เกิดขึ้นห่างออกไปหนึ่งชั่วโมงจากเวลาเดียวกันบนนาฬิกาในวันนี้ นั่นคือการทำงานของ tz database

มันเป็นแบบข้อความ อ่านได้โดยมนุษย์ และมีขนาดเล็ก รูปแบบไบนารีที่คอมไพล์แล้วซึ่งมาพร้อมกับคอมพิวเตอร์ของคุณมีขนาดเพียงไม่กี่เมกะไบต์ แต่มันเข้ารหัสชุดข้อมูลที่ซับซ้อนอย่างเงียบๆ หนึ่งในชุดข้อมูลที่ซับซ้อนที่สุดในโลกคอมพิวเตอร์

ประวัติโดยย่อ

โครงการเริ่มต้นในทศวรรษ 1980 ภายใต้ Arthur David Olson ซึ่งรวบรวมเวอร์ชันแรกและโฮสต์ไว้บนเซิร์ฟเวอร์ของสถาบันสุขภาพแห่งชาติสหรัฐอเมริกา เป็นเวลาหลายทศวรรษที่มันถูกดูแลโดยอาสาสมัครเป็นหลักผ่านทางรายชื่ออีเมลสาธารณะ ซึ่งเป็นเหตุผลว่าทำไมชื่อเก่า "Olson database" ยังคงปรากฏในเอกสาร

Paul Eggert รับหน้าที่เป็นบรรณาธิการหลักและยังคงเป็นผู้ประสานงานระยะยาวของโครงการ การรวบรวมเอกสาร theory.html ที่มาพร้อมกันและประวัติการคอมมิตที่พิถีพิถันทำให้ฐานข้อมูลนี้กลายเป็นทั้งเอกสารอ้างอิงทางประวัติศาสตร์และทางเทคนิค

ในปี 2011 หลังจากข้อพิพาททางกฎหมายที่สั้นแต่น่าตกใจเกี่ยวกับข้อมูลทางประวัติศาสตร์ การดูแลได้ย้ายไปยัง Internet Assigned Numbers Authority (IANA) ซึ่งเป็นหน่วยงานเดียวกับที่ประสานงานทรัพยากรอินเทอร์เน็ตหลักอื่นๆ ปัจจุบัน IANA เผยแพร่รุ่นอย่างเป็นทางการ ซึ่งเป็นเหตุผลว่าทำไม "IANA time zone database" จึงกลายเป็นชื่อมาตรฐาน งานยังคงทำโดยชุมชนผู้มีส่วนร่วมเดียวกัน IANA ให้บ้านสถาบันและจุดกระจายที่เสถียร

หลักการตั้งชื่อ: Area/Location

หนึ่งในคุณสมบัติที่โดดเด่นที่สุดของฐานข้อมูลคือวิธีตั้งชื่อเขตเวลา แทนที่จะใช้ชื่อประเทศหรือ offset ดิบ มันใช้รูปแบบ Area/Location ซึ่งมักจะยึดตามเมืองตัวแทน:

• America/New_York
• Europe/London
• Asia/Kolkata
• Australia/Sydney

"Area" มักจะเป็นทวีปหรือมหาสมุทร (America, Europe, Asia, Pacific) และ "Location" เป็นเมืองที่รู้จักกันดีภายในเขตเวลา ตัวเลือกนี้ดูแปลกจนกว่าคุณจะเข้าใจเหตุผลที่อยู่เบื้องหลัง

เมืองมีความเสถียร; เขตการเมืองและ offset ไม่ใช่ ประเทศแยกตัว รวมตัว เปลี่ยนชื่อ และเปลี่ยนนาฬิกา ในทางตรงกันข้าม เมืองคือจุดทางภูมิศาสตร์ที่คงที่ซึ่งมีประวัติการวัดเวลาอย่างต่อเนื่อง การตั้งชื่อเขตเวลา America/New_York แทนที่จะเป็น "US Eastern Time" หรือ "UTC-5" หมายความว่าตัวระบุยังคงใช้ได้แม้ว่า กฎ ที่แนบมากับมันจะเปลี่ยนไป

ฐานข้อมูลยัง จงใจหลีกเลี่ยงชื่อประเทศ เพื่อหลีกเลี่ยงข้อพิพาททางการเมือง และเนื่องจากประเทศเดียวมักมีหลายเขตเวลา — สหรัฐอเมริกามีมากกว่าหนึ่งโหล มันเลือกเมืองที่มีประชากรมากที่สุดหรือมีประวัติศาสตร์สำคัญที่สุดในแต่ละเขตเวลาที่แตกต่างกันเป็นป้ายที่เป็นกลาง เมื่อสองภูมิภาคมีประวัตินาฬิกาที่เหมือนกันตั้งแต่ปี 1970 พวกเขาใช้เขตเวลาเดียวกัน; ทันทีที่ประวัติศาสตร์ของพวกเขาแตกต่าง พวกเขาจะได้รับรายการแยกต่างหาก

ทำไม offset ดิบไม่เพียงพอ

สัญชาตญาณของผู้เริ่มต้นทั่วไปคือการจัดเก็บเวลาเป็น "UTC+5:30" แล้วจบลง วิธีนี้ใช้ได้สำหรับช่วงเวลาหนึ่ง แต่ใช้ไม่ได้ทันทีที่คุณต้องคิดเกี่ยวกับเหตุการณ์ ในอนาคต หรือ ที่เกิดซ้ำ เนื่องจาก offset ไม่ใช่คุณสมบัติคงที่ของสถานที่ พวกมันคือ ผลลัพธ์ ของกฎที่รัฐบาลเปลี่ยนแปลงตลอดเวลาและบ่อยครั้งอย่างฉับพลัน

ลองพิจารณาตัวอย่างจริงสองสามตัวอย่างที่ฐานข้อมูลต้องดูดซับ:

• ซามัวข้ามวันที่ 30 ธันวาคม 2011 ทั้งหมด เพื่อให้วันทำการสอดคล้องกับออสเตรเลียและนิวซีแลนด์แทนที่จะเป็นสหรัฐอเมริกา ซามัวกระโดดข้ามเส้นวันที่สากล จาก UTC-11 ไปเป็น UTC+13 สำหรับใครก็ตามบนเกาะนั้น วันศุกร์นั้นไม่มีอยู่จริง
• ประเทศต่างๆ ยกเลิก ใช้ หรือเปลี่ยนเวลาออมแสงโดยแจ้งล่วงหน้าน้อย สหภาพยุโรปได้ถกเถียงเรื่องการยุติ DST; หลายประเทศและหลายรัฐในสหรัฐอเมริกาได้เปลี่ยนกฎ DST ในช่วงไม่กี่ทศวรรษที่ผ่านมา ตุรกี รัสเซีย และอื่นๆ ได้เปลี่ยนแปลง offset มาตรฐานของตนโดยสิ้นเชิง
• วันที่เริ่มต้นและสิ้นสุด DST เลื่อน สหรัฐอเมริกาเปลี่ยนขอบเขต DST ในปี 2007 ระบบใดก็ตามที่เขียนกฎเก่าไว้ตายตัวจะสร้างเวลาที่ผิดอย่างเงียบๆ เป็นเวลาหลายสัปดาห์ในแต่ละปี

หากคุณจัดเก็บเฉพาะ offset คุณไม่สามารถตอบคำถาม "เวลาท้องถิ่นในซานติอาโกในวันที่ 15 พฤศจิกายนปีหน้าจะเป็นเท่าใด" เพราะคำตอบขึ้นอยู่กับกฎที่อาจยังไม่ได้รับการสรุป การจัดเก็บ ตัวระบุเขตเวลา (America/Santiago) พร้อมกับฐานข้อมูลช่วยให้ซอฟต์แวร์คำนวณ offset ที่ถูกต้องสำหรับช่วงเวลาใดๆ ทั้งอดีตและอนาคต และคำนวณใหม่โดยอัตโนมัติเมื่อกฎเปลี่ยนไป

นี่คือข้อเสนอคุณค่าหลัก: tz database แยก ตัวตน ของสถานที่ออกจาก กฎที่เปลี่ยนแปลงตลอดเวลา ที่กำหนดนาฬิกาของมัน

วิธีการดูแลรักษา

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

รุ่นต่างๆ จะถูกกำหนดเวอร์ชันด้วยปีและตัวอักษร: 2024a, 2024b, 2024c และอื่นๆ ตัวเลขคือปี; ตัวอักษรเพิ่มขึ้นตามแต่ละรุ่นในปีนั้น เนื่องจากรัฐบาลประกาศการเปลี่ยนแปลงนาฬิกาตามตารางเวลาที่ไม่แน่นอนของตนเอง จึงไม่มีกำหนดการเผยแพร่ที่แน่นอน — ปีที่เงียบสงบอาจมีสองรุ่น ในขณะที่ปีที่มีความวุ่นวายทางการเมืองอาจมีหลายรุ่น ระบบต่างๆ คาดว่าจะอัปเดตอย่างทันท่วงที เนื่องจากฐานข้อมูลที่ล้าสมัยอาจหมายถึงการแสดงเวลาที่ผิดหลังจากกฎมีผลบังคับใช้

ใครบ้างที่พึ่งพามัน

เกือบทุกอย่าง

• ระบบปฏิบัติการ ลีนุกซ์ดิสทริบิวชันจัดส่ง tzdata เป็นแพ็คเกจหลัก macOS นำข้อมูลเขตเวลามาจากแหล่งเดียวกัน Windows ใช้เขตเวลาที่ใช้รีจิสทรีของตัวเองสำหรับเหตุผลทางมรดก แต่เปิดเผยเขตเวลา IANA ผ่านไลบรารี ICU และ API ที่ทันสมัย
• ภาษาโปรแกรม ไลบรารีวันที่/เวลาที่เป็นผู้ใหญ่ทุกตัวอ่านหรือรวม tz database: zoneinfo ของ Python, java.time ของ Java, โครงการ ICU, PostgreSQL, เอ็นจิน JavaScript ผ่าน ICU, Ruby, PHP และอื่นๆ อีกมากมาย
• แอปพลิเคชัน ปฏิทิน ระบบจอง แพลตฟอร์มการซื้อขายทางการเงิน เครื่องมือวิเคราะห์บันทึก และบริการจัดตารางเวลาทั้งหมดพึ่งพามัน มักจะโดยที่นักพัฒนาไม่ต้องคิดถึงมัน

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

หากคุณต้องการสำรวจเขตเวลาด้วยตนเอง เรียกดูรายการทั้งหมดของ เขตเวลา IANA หรือดูว่าเขตเวลาเหล่านั้นแมปทั่วโลกในไดเรกทอรีของ ทุกเขตเวลา

คำถามที่พบบ่อย

tz database เหมือนกับ tzdata, zoneinfo และ Olson database หรือไม่

ใช่ ทั้งหมดนี้เป็นชื่อของโครงการเดียวกัน "tzdata" มักจะหมายถึงไฟล์ข้อมูลที่บรรจุเป็นแพ็คเกจสำหรับระบบปฏิบัติการ "zoneinfo" หมายถึงไดเรกทอรีไบนารีที่คอมไพล์แล้ว และ "Olson database" เป็นชื่อทางประวัติศาสตร์ที่เก่ากว่าตามผู้ก่อตั้ง Arthur David Olson ปัจจุบันชื่อทางการคือ IANA Time Zone Database

ฐานข้อมูลได้รับการอัปเดตบ่อยแค่ไหน?

ไม่มีกำหนดการที่แน่นอน รุ่นต่างๆ ถูกกระตุ้นโดยเหตุการณ์ในโลกจริง — รัฐบาลเปลี่ยนกฎ DST หรือ offset มาตรฐาน หรือการแก้ไขข้อมูลทางประวัติศาสตร์ บางปีมีรุ่นเดียว; บางปีมีหลายรุ่น แต่ละรุ่นตั้งชื่อเช่น 2024a, 2024b โดยเพิ่มตัวอักษรตลอดทั้งปี

ทำไมมันตั้งชื่อเขตเวลาตามเมืองเช่น America/New_York?

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

ฉันสามารถจัดเก็บ offset UTC แทนชื่อเขตเวลาได้หรือไม่?

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

ใครเป็นผู้ดำเนินโครงการนี้ในปัจจุบัน?

มันเผยแพร่โดย IANA ซึ่งรับช่วงการดูแลในปี 2011 และประสานงานโดย Paul Eggert กับชุมชนผู้มีส่วนร่วมที่ทำงานผ่านรายชื่ออีเมล tz สาธารณะ งานทางเทคนิคยังคงเป็นความร่วมมือที่ขับเคลื่อนโดยอาสาสมัคร