Basis Data Zona Waktu IANA (tz): Apa Itu dan Mengapa Penting

Apa Sebenarnya IANA Time Zone Database Itu

Jika Anda pernah bekerja dengan tanggal dan waktu dalam perangkat lunak, Anda telah mengandalkan IANA Time Zone Database, baik Anda sadari atau tidak. Basis data ini memiliki beberapa nama — tz database, tzdata, Olson database, atau zoneinfo — tetapi semuanya merujuk pada hal yang sama: sebuah katalog kolaboratif yang tersedia secara bebas tentang zona waktu dunia dan aturan yang mengaturnya.

Kata "katalog" sebenarnya kurang tepat. Basis data ini tidak sekadar mendaftar wilayah mana yang berada pada offset UTC tertentu. Basis data ini mencatat sejarah lengkap pencatatan waktu sipil untuk setiap wilayah — setiap perubahan offset, setiap transisi waktu musim panas, setiap pergeseran jam masa perang, dan setiap aturan masa depan yang dijadwalkan — yang dalam banyak kasus, dimulai sejak pertengahan abad ke-19 ketika waktu rata-rata lokal digantikan oleh zona standar. Ketika aplikasi kalender Anda dengan benar menunjukkan bahwa sebuah rapat pada tahun 1985 terjadi satu jam lebih awal dari waktu dinding yang sama hari ini, itulah kerja tz database.

Basis data ini berbasis teks, dapat dibaca manusia, dan berukuran kecil. Bentuk biner yang telah dikompilasi yang ada di komputer Anda hanya berukuran beberapa megabita. Namun, basis data ini menyandikan salah satu kumpulan data yang paling rumit secara diam-diam dalam komputasi.

Sejarah Singkat

Proyek ini dimulai pada tahun 1980-an di bawah Arthur David Olson, yang menyusun versi pertama dan menghostingnya di server di Institut Kesehatan Nasional AS. Selama beberapa dekade, proyek ini sebagian besar dipelihara melalui upaya sukarela yang dikoordinasikan melalui milis publik, itulah sebabnya nama lama "Olson database" masih muncul dalam dokumentasi.

Paul Eggert mengambil alih sebagai editor utama dan tetap menjadi koordinator jangka panjang proyek ini. Kompilasinya atas dokumen theory.html yang menyertainya dan riwayat komit yang cermat telah menjadikan basis data ini sebagai referensi sejarah sekaligus teknis.

Pada tahun 2011, setelah perselisihan hukum yang singkat namun mengkhawatirkan atas data historis, pengelolaan beralih ke Internet Assigned Numbers Authority (IANA) , badan yang sama yang mengoordinasikan sumber daya internet inti lainnya. IANA sekarang menerbitkan rilis resmi, itulah sebabnya "IANA time zone database" menjadi nama kanonik. Pekerjaan masih dilakukan oleh komunitas kontributor yang sama; IANA menyediakan rumah institusional dan titik distribusi yang stabil.

Konvensi Penamaan: `Area/Location`

Salah satu fitur paling khas dari basis data ini adalah bagaimana ia menamai zona. Alih-alih menggunakan nama negara atau offset mentah, ia menggunakan format Area/Location, yang hampir selalu berlabuh ke kota perwakilan:

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

"Area" biasanya adalah benua atau samudra (America, Europe, Asia, Pacific), dan "Location" adalah kota terkenal di dalam zona tersebut. Pilihan ini terlihat aneh sampai Anda memahami alasan di baliknya.

Kota itu stabil; batas politik dan offset tidak. Negara-negara terpecah, bergabung, mengganti nama, dan mengubah jam mereka. Sebuah kota, sebaliknya, adalah titik geografis tetap dengan sejarah pencatatan waktu yang berkelanjutan. Menamai zona America/New_York daripada "US Eastern Time" atau "UTC-5" berarti pengenal tetap valid bahkan ketika aturan yang melekat padanya berkembang.

Basis data juga dengan sengaja menghindari nama negara untuk menghindari perselisihan politik dan karena satu negara sering kali berisi beberapa zona — Amerika Serikat memiliki lebih dari selusin. Basis data ini memilih kota terpadat atau paling signifikan secara historis di setiap zona yang berbeda sebagai label netral. Ketika dua wilayah memiliki sejarah jam yang identik sejak tahun 1970, mereka berbagi satu zona; saat sejarah mereka berbeda, mereka mendapatkan entri terpisah.

Mengapa Offset Mentah Tidak Cukup

Insting umum pemula adalah menyimpan waktu sebagai "UTC+5:30" dan menganggapnya selesai. Ini berfungsi untuk satu momen, tetapi akan runtuh saat Anda perlu bernalar tentang peristiwa masa depan atau berulang, karena offset bukanlah properti statis dari suatu tempat. Offset adalah keluaran dari aturan yang diubah pemerintah secara konstan dan seringkali mendadak.

Pertimbangkan beberapa contoh nyata yang harus diserap oleh basis data:

Samoa melewatkan seluruh tanggal 30 Desember 2011. Untuk menyelaraskan hari bisnisnya dengan Australia dan Selandia Baru daripada Amerika Serikat, Samoa melompati Garis Tanggal Internasional, berpindah dari UTC-11 ke UTC+13. Bagi siapa pun di pulau itu, hari Jumat itu tidak pernah ada.
Negara-negara menghapuskan, mengadopsi, atau menjadwalkan ulang waktu musim panas dengan sedikit pemberitahuan. Uni Eropa telah memperdebatkan penghentian DST; beberapa negara bagian AS telah mengubah aturan DST mereka dalam beberapa dekade terakhir. Turki, Rusia, dan lainnya telah mengubah offset standar mereka secara langsung.
Tanggal mulai dan berakhirnya DST bergeser. Amerika Serikat memindahkan batas DST-nya pada tahun 2007. Sistem apa pun yang mengkodekan aturan lama secara diam-diam menghasilkan waktu yang salah selama berminggu-minggu setiap tahun.

Jika Anda hanya menyimpan offset, Anda tidak dapat menjawab pertanyaan "berapa waktu lokal di Santiago pada tanggal 15 November tahun depan?" — karena jawabannya tergantung pada aturan yang mungkin belum final. Menyimpan pengenal zona (America/Santiago) ditambah basis data memungkinkan perangkat lunak menghitung offset yang benar untuk setiap momen, masa lalu atau masa depan, dan menghitung ulang secara otomatis ketika aturan berubah.

Ini adalah proposisi nilai inti: tz database memisahkan identitas suatu tempat dari aturan yang selalu berubah yang menentukan jamnya.

Bagaimana Cara Pemeliharaannya

Pemeliharaan terjadi secara terbuka. Perubahan yang diusulkan — aturan DST baru, tanggal historis yang dikoreksi, pengumuman pemerintah — didiskusikan di milis publik tz, di mana kontributor mengutip lembaran negara resmi, laporan berita, dan keputusan pemerintah sebagai bukti. Akurasi ditangani dengan serius; perubahan pada data historis khususnya diteliti terhadap sumber primer.

Rilis diberi versi dengan tahun dan huruf: 2024a, 2024b, 2024c, dan seterusnya. Angka adalah tahunnya; huruf bertambah dengan setiap rilis pada tahun itu. Karena pemerintah mengumumkan perubahan jam pada jadwal mereka sendiri yang tidak dapat diprediksi, tidak ada irama rilis yang tetap — tahun yang tenang mungkin melihat dua rilis, sementara tahun dengan gejolak politik melihat banyak rilis. Sistem diharapkan untuk memperbarui dengan cepat, karena basis data yang basi dapat berarti menampilkan waktu yang salah setelah perubahan aturan berlaku.

Siapa yang Bergantung Padanya

Hampir semuanya.

Sistem operasi. Distribusi Linux mengirimkan tzdata sebagai paket inti. macOS memperoleh data zona dari sumber yang sama. Windows menggunakan zona berbasis registrinya sendiri untuk alasan warisan tetapi mengekspos zona IANA melalui pustaka ICU dan API modern.
Bahasa pemrograman. Hampir setiap pustaka tanggal/waktu yang matang membaca dari atau menggabungkan tz database: zoneinfo Python, java.time Java, proyek ICU, PostgreSQL, mesin JavaScript melalui ICU, Ruby, PHP, dan banyak lagi.
Aplikasi. Kalender, sistem pemesanan, platform perdagangan keuangan, alat analisis log, dan layanan penjadwalan semuanya bergantung padanya, biasanya tanpa dipikirkan oleh pengembangnya.

Keberadaan di mana-mana inilah yang membuat basis data ini sangat penting. Satu sumber kebenaran tunggal, bersama, dan dipelihara dengan hati-hati berarti rapat yang dijadwalkan di satu sistem ditampilkan dengan benar di sistem lain, di seluruh sistem operasi dan bahasa, puluhan tahun ke masa lalu atau masa depan.

Jika Anda ingin menjelajahi zona itu sendiri, jelajahi daftar lengkap zona waktu IANA atau lihat bagaimana zona-zona tersebut dipetakan di seluruh dunia di direktori semua zona waktu kami.

Pertanyaan yang Sering Diajukan

Apakah tz database sama dengan tzdata, zoneinfo, dan Olson database?

Ya. Ini semua adalah nama untuk proyek yang sama. "tzdata" biasanya merujuk pada file data yang dikemas untuk sistem operasi, "zoneinfo" ke direktori biner yang dikompilasi, dan "Olson database" adalah nama historis yang lebih lama setelah pendiri Arthur David Olson. Saat ini nama resminya adalah IANA Time Zone Database.

Seberapa sering basis data diperbarui?

Tidak ada jadwal tetap. Rilis dipicu oleh peristiwa dunia nyata — pemerintah mengubah aturan DST atau offset standarnya, atau koreksi pada data historis. Beberapa tahun melihat satu rilis; yang lain melihat beberapa. Masing-masing dinamai seperti 2024a, 2024b, dengan huruf bertambah sepanjang tahun.

Mengapa ia menamai zona setelah kota seperti `America/New_York`?

Kota secara geografis tetap dan memiliki sejarah pencatatan waktu yang berkelanjutan, sedangkan negara, perbatasan, dan offset berubah seiring waktu. Menggunakan kota perwakilan memberikan setiap zona pengenal yang stabil dan netral secara politik yang tetap valid bahkan ketika aturan DST atau offset yang mendasarinya berubah.

Bisakah saya hanya menyimpan offset UTC alih-alih nama zona?

Hanya untuk satu momen tetap. Untuk peristiwa masa depan atau berulang, Anda harus menyimpan pengenal zona, karena offset berubah dengan waktu musim panas dan keputusan pemerintah. Nama zona ditambah basis data memungkinkan perangkat lunak menghitung offset yang benar untuk tanggal apa pun secara otomatis.

Siapa yang menjalankan proyek sekarang?

Proyek ini diterbitkan oleh IANA, yang mengambil alih pengelolaan pada tahun 2011, dan dikoordinasikan oleh Paul Eggert dengan komunitas kontributor yang bekerja melalui milis publik tz. Pekerjaan teknis tetap merupakan upaya kolaboratif yang digerakkan oleh sukarelawan.