IANA saat dilimi

Bir IANA saat dilimi, orijinal sorumlusu Arthur David Olson'ın adıyla "tzdata" veya "Olson veritabanı" olarak da bilinen IANA Saat Dilimi Veritabanı'ndan Europe/London, America/New_York veya Asia/Tokyo gibi kurallı bir tanımlayıcıdır.

Her giriş, bir bölge için UTC farkı ve yaz saati davranışına ait her tarihsel ve güncel kuralı yakalar. "Europe/London" şunları kodlar: kışın GMT (UTC+0), yazın BST (UTC+1), kesin yaz saati geçiş tarihleri ve 1971 öncesi tarihsel özellikler. Bir tarih ve dilimi herhangi bir modern programlama diline yapıştırmak, tzdata işletim sistemine yerleşik olduğu için doğru farkı döndürür.

Adlandırma kuralı Bölge/Şehir şeklindedir; Bölge şunlardan biridir: Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific ile özel UTC, Etc/GMT vb. Şehir, dilim içindeki kurallı bir şehirdir — Istanbul tüm Türkiye'yi temsil eder, New_York ABD Doğu saat dilimini ve benzeri.

Convertitive'nin saat dilimi dönüştürücüsü,Intl.DateTimeFormat aracılığıyla tarayıcının işletim sistemi düzeyindeki tzdata'sını kullanır; bu nedenle yaz saati geçişleri ve fark değişiklikleri, Convertitive'nin güncelleme göndermesine gerek kalmadan her zaman günceldir.

Çalışılmış örnek

New York, Londra ve Tokyo'daki katılımcılar için "Salı 09:00 New York saatiyle" haftalık düzenli bir ekip toplantısı planlıyorsunuz. Toplantıyı { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" } olarak saklayın. Londra katılımcısının takvimi her tekrarı çözümler: Ocak'ta NY, EST'de (UTC−5) ve Londra GMT'de (UTC+0), dolayısıyla toplantı Londra saatiyle 14:00'tür. Mart'ta (ABD yaz saatinden sonra, AB yaz saatinden önce), NY EDT'de (UTC−4) ve Londra GMT'de, dolayısıyla toplantı Londra saatiyle 13:00 — bir saat öne alındı. Haziran'da her ikisi de yaz saatinde, NY EDT (UTC−4) ve Londra BST (UTC+1), dolayısıyla toplantı yeniden Londra saatiyle 14:00. Tokyo (UTC+9, yaz saati yok) toplantının mevsime göre 22:00 ile 23:00 arasında kaydığını görür. Şimdi ekibin toplantıyı "14:00 UTC" olarak sakladığını düşünün — NY katılımcısı, yaz saati değiştikçe toplantı saatinin ileri geri kaydığını yaşar ve "Salı sabahı saat 9" geleneği yılda iki kez sessizce bozulur.

Ne zaman ve neden önemli

IANA saat dilimleri, bir sistem birden fazla kullanıcı, birden fazla konum veya birden fazla mevsimde tarihleri işlediği anda önemlidir. Depolamada kaçınılacak hata sabit farkları kullanmaktır — "Asia/Karachi" gelecekteki bir yaz saati yeniden tanımından sağ çıkar; "UTC+5" çıkamaz. Görüntülemede kaçınılacak hata, zaman damgalarını hedef dilimi belirtmeden oluşturmaktır — dilim etiketi olmadan "2026-05-22 14:30" gösteren bir arka uç günlüğü belirsiz ve aranamaz. İş mantığında kaçınılacak hata, yaz saati geçişleri etrafında "1 gün ekle" aritmetiğini yerel saat yerine UTC'de yapmaktır — "ertesi gün aynı duvar saati zamanı" yaz saatinin o gece başlayıp başlamadığına bağlı olarak UTC'de 23 veya 25 saat uzakta olabilir. Modern datetime kütüphaneleri (JavaScript'in Temporal API'si, Python'un zoneinfo'su, Java'nın java.time'ı), IANA tanımlayıcıları verildiğinde bunu doğru biçimde ele alır; eski API'ler (JavaScript'in yerel Date'i, saat dilimi eklentisi olmadan moment.js) sessizce yanlış yanıtlar üretir. Referans: RFC 6557 — Saat Dilimi Veritabanını Sürdürme Prosedürleri.

IANA tzdata yayın döngüsü: tzdata yayınları yıl + küçük harf ile sürümlenir — 2024a, 2024b, 2025a ve benzeri. Bir hükümet yaz saati kurallarını veya bir bölgenin saat dilimi farkını değiştirdiğinde, talep üzerine genellikle yılda 4-8 kez yayın yapılır. Son dikkate değer değişiklikler: Meksika 2022'de ülke genelinde yaz saatini kaldırdı; Rusya birden fazla revizyon boyunca kalıcı kış saatini kaldırıp geri getirdi; Lübnan 2023'te siyasi bir anlaşmazlık nedeniyle yaz saatine bir hafta gecikmeli geçti. Her işletim sistemi değişiklikleri rutin paket güncellemeleri aracılığıyla alır — ancak otomatik güncelleme yapmayan IoT cihazlar ve eski telefonlar kayabilir; bu durum yaz saati kural değişikliğinin ardından ilk haftada klasik "alarm saatim bir saat geride" sorununa yol açar.

Farkları hiçbir zaman doğrudan saklamamanızın nedeni: datetime kodundaki en yaygın hata, Europe/Istanbul yerine "UTC+2" saklamaktır. Fark, bölgenin anlık bir gerçeğini yakalar ama kuralları değil. Türkiye yaz saatini yeniden başlatırsa (2016'da kaldırdı, ancak kural değişiklikleri bölgede yaygındır), "UTC+2" bulunan her kayıt bir gecede yanlış hale gelir. IANA dilim tanımlayıcısını saklayın ve aramanın her zaman damgası için doğru farkı hesaplamasına izin verin. İlgili: UTC, artık saniye. Referans: IANA Saat Dilimi Veritabanı.