Saat Dilimlerini, UTC'yi ve Unix Zaman Damgalarını Anlamak

Zaman, doğru şekilde işleyen bir yazılım yazmaya çalışana kadar basit görünür. "Öğleden sonra 3" olarak planlanan bir etkinlik Tokyo, Londra ve New York'ta farklı anlamlara gelir. Yaz saati uygulaması saatleri ileri veya geri alır — ama her yerde değil ve aynı tarihlerde değil. Yerel ortamınızda doğru görünen bir zaman damgası, sunucunun farklı bir bölgede olması nedeniyle üretimde bozulur.

Saat dilimleri, yazılım geliştirmede güvenilir biçimde kafa karıştıran konulardan biridir. Bu makale nasıl çalıştıklarını, karmaşıklığın nereden geldiğini ve en yaygın hatalardan nasıl kaçınılacağını açıklar.

Saat dilimleri neden var

Dünya 24 saatte 360 derece döner, bu da güneşin en yüksek noktada olduğu anın boylamınıza göre farklılık gösterdiği anlamına gelir. 19. yüzyıldan önce her şehir saatlerini yerel güneş saatine göre ayarlardı — öğle vakti güneşin tepede olduğu andı. Bu, demiryolları uzak şehirleri birbirine bağlayana ve bir tren tarifesinin tek, tutarlı bir saate ihtiyaç duymasına kadar iyi çalıştı.

1884'te 25 ulustan temsilciler Washington, D.C.'deki Uluslararası Meridyen Konferansı'nda bir araya geldi ve dünyayı, Greenwich, İngiltere'den geçen başlangıç meridyeninden (0 derece boylam) fark edilen 24 standart saat dilimine bölmeyi kabul etti.

Pratikte, saat dilimi sınırları düzgün boylam çizgilerini değil, siyasi sınırları takip eder. Çin beş coğrafi bölge kapsar ama tek bir resmi saat (UTC+8) kullanır. Hindistan UTC+5:30 kullanır — yarım saatlik bir fark. Nepal UTC+5:45 kullanır. Gerçek dünya saat dilimleri haritası karmaşıktır.

UTC ve GMT

GMT (Greenwich Mean Time), Greenwich'teki Kraliyet Gözlemevi'ndeki ortalama güneş saatidir. Bir yüzyıldan fazla dünya zaman referansı olmuştur.

UTC (Coordinated Universal Time), 1972'de GMT'nin yerini uluslararası standart olarak almıştır. UTC, astronomik gözlem yerine atom saatlerine dayanır ve bu onu çok daha hassas kılar. Pratik amaçlar için UTC ve GMT aynı saati gösterir, ancak doğru teknik referans UTC'dir.

Yaz saati uygulaması: düzenli kaos

Yaklaşık 70 ülke yaz saati uygulamasını (DST) gözlemler; ilkbaharda saatleri bir saat ileri, sonbaharda geri alır. Amaç, uyanık olunan saatleri gün ışığıyla hizalamaktır. Sonuç, yılda iki kez yaşanan hata kaynağıdır.

Temel komplikasyonlar:

• Evrensel değil. Afrika, Asya ve Güney Amerika'nın çoğu DST uygulamaz. ABD içinde Arizona ve Hawaii dışında kalır.
• Farklı tarihler. AB, Mart'ın son pazarı ve Ekim'in son pazarı geçiş yapar. ABD, Mart'ın ikinci pazarı ve Kasım'ın ilk pazarı geçiş yapar. Her yıl birkaç hafta senkronize değildirler.
• Belirsiz saatler. Saatler geri alındığında, 01:00'den 02:00'ye kadar olan saat iki kez gerçekleşir. O gün "01:30" zaman damgası belirsizdir.
• Atlanan saatler. Saatler ileri alındığında, 02:00'den 03:00'e kadar olan saat mevcut değildir. O gün 02:30'a planlanan bir toplantı asla gerçekleşmez.
• Siyasi değişiklikler. Hükümetler az bir uyarıyla DST kurallarını değiştirebilir (ve değiştirirler). Rusya 2011'de kalıcı yaz saatini benimsedi, ardından 2014'te kalıcı standart saate geçti. Fas, DST kurallarını birçok kez değiştirmiştir.

ISO 8601: evrensel tarih formatı

Belirsizliği önlemek için uluslararası standart ISO 8601 net bir tarih ve saat formatı tanımlar:

2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00

• T tarihi saatten ayırır.
• Z UTC anlamına gelir (askeri terminolojide "Zulu" saat dilimi).
• +02:00 veya -05:00 UTC farkıdır.

Bu format belirsiz değildir, düz metin olarak sıralanabilir ve tarih ayrıştırma kütüphaneleri tarafından evrensel olarak anlaşılır. Şüphe duyduğunuzda ISO 8601 kullanın.

Unix zaman damgaları

Unix zaman damgası (epoch time veya POSIX time olarak da adlandırılır), 1 Ocak 1970, 00:00:00 UTC'den — Unix epoch olarak bilinen bir an — bu yana geçen saniye sayısıdır.

Unix zaman damgalarının saat dilimi yoktur — her zaman UTC'dedir. Bu onları yazılımda zamanları saklamak ve karşılaştırmak için ideal kılar. Yerel saat dilimine dönüşümü yalnızca görüntüleme katmanında yaparsınız.

IANA saat dilimi veritabanı

Yazılım sadece UTC farklarına değil, DST geçişleri, siyasi değişiklikler ve tarihsel anormallikler dahil her bölgenin tam tarihçesine ve gelecek kurallarına ihtiyaç duyar. Bu bilgi IANA Saat Dilimi Veritabanı'nda (Olson veritabanı veya tzdata olarak da bilinir) bulunur.

America/New_York, Europe/Paris, Asia/Tokyo gibi tanımlayıcılar kullanır. Her giriş, o konum için UTC farklarının ve DST kurallarının tam tarihçesini kodlar.

Bu nedenle bir saat dilimini asla "+02:00" gibi sabit bir fark olarak saklamamalısınız. Bir fark size UTC'den mevcut farkı söyler ama DST kuralları hakkında hiçbir şey söylemez. Europe/Paris kışın UTC+1, yazın UTC+2'dir. IANA tanımlayıcısı her ikisini de yakalar.

Yazılımdaki yaygın hatalar

1. Saat dilimi olmadan yerel saat saklamak. 2026-03-29 14:30:00 gibi bir değer, hangi saat dilimine atıfta bulunduğunu bilmeden anlamsızdır. Her zaman UTC saklayın veya farkı dahil edin.
2. UTC farkının saat dilimine eşit olduğunu varsaymak. Mart'ta UTC+2, Temmuz'da UTC+3 olabilir (bölge DST uyguluyorsa). Farkı değil, IANA tanımlayıcısını saklayın.
3. Zamanlamada DST geçişlerini göz ardı etmek. 02:30'daki günlük bir görev, DST'yi işlemiyorsanız yılda bir kez atlanacak ve bir kez iki kere çalışacaktır.
4. Günlerin 24 saat olduğunu varsaymak. DST geçiş günlerinde bir gün 23 veya 25 saattir. "Yarın aynı saatte"yi 86.400 saniye ekleyerek hesaplamak bir saat yanılır.
5. JavaScript Date'i saf şekilde kullanmak. new Date("2026-03-29") bazı motorlarda UTC olarak, diğerlerinde yerel saat olarak ayrıştırılır. Saat dilimi konusunda her zaman açık olun.

Geliştiriciler için en iyi uygulamalar

• Zamanları UTC'de saklayın. Kullanıcının yerel saat dilimine dönüşümü yalnızca sunum katmanında yapın.
• IANA saat dilimi tanımlayıcılarını kullanın (America/New_York), sabit farkları değil (-05:00).
• Serileştirme için ISO 8601 kullanın. Belirsiz değildir ve evrensel olarak ayrıştırılabilir.
• Olgun bir tarih kütüphanesi kullanın. JavaScript'te Intl.DateTimeFormat veya date-fns-tz gibi bir kütüphane kullanın. Python'da zoneinfo (3.9+) veya pytz kullanın. Java'da java.time.ZonedDateTime kullanın.
• tzdata'yı güncel tutun. Hükümetler DST kurallarını değiştirir. İşletim sisteminizin ve dil çalışma zamanınızın güncel saat dilimi verilerine ihtiyacı vardır.
• Birden fazla saat dilimiyle test edin. Sunucunuzun ve kullanıcılarınızın aynı bölgede olduğunu varsaymayın.

Daha fazlası

Zaman aldatıcı biçimde karmaşıktır, ancak kurallar iyi belgelenmiştir ve araçlar olgunlaşmıştır. Anahtar, karmaşıklığı yok saymak yerine ona saygı duymaktır.

• Cron İfadeleri Açıklandı — saat dilimleri arasında görev zamanlama
• Hash Oluşturucu ve Regex Test Aracı — ToolK'ta daha fazla geliştirici aracı