Saat Dilimleri, Yaz Saati ve Tarih Hesaplamayı Hatasız Yapma Rehberi
Zamanla çalışmak, yazılımın en sinsi tuzaklarından biridir. "Bir gün 24 saattir" gibi masum bir varsayım, yaz saati geçişlerinde uygulamanızı bir saat kaydırabilir; "saat farkı sabittir" varsayımı ise yanlış randevu saatlerine yol açar. Bu rehberde saat dilimleriyle, yaz saatiyle ve tarih hesaplamayla baş etmenin pratik yollarını sade bir dille anlatıyoruz.
UTC ile Yerel Saat Arasındaki Fark
Her şeyin temelinde UTC (Eşgüdümlü Evrensel Zaman) vardır. UTC, dünyanın tek ve değişmeyen referans saatidir; yaz saati uygulamaz, kaymaz, tartışmaya açık değildir. Yerel saat ise her zaman bir UTC ofseti ile ifade edilir. Örneğin Türkiye saati UTC+3'tür.
Altın kural şudur: mantığı UTC üzerinde kur, kullanıcıya yerel saatle göster. Sunucularda, veritabanında ve hesaplamalarda hep UTC kullanın; ekrana basarken kullanıcının saat dilimine çevirin. Böylece bir saat hesabı, kullanıcının nerede olduğundan bağımsız olarak doğru kalır.
IANA Saat Dilimleri: Ofset Değil, Bölge
Yaygın bir hata, saat dilimini "UTC+3" gibi sabit bir ofset olarak saklamaktır. Sorun şu: ofsetler yıl içinde değişir. Yaz saati uygulayan ülkelerde aynı şehir kışın UTC+1, yazın UTC+2 olabilir.
Doğru yaklaşım IANA saat dilimi adlarını kullanmaktır: Europe/Istanbul, America/New_York, Asia/Tokyo gibi. Bu adlar yalnızca bir ofset değil, o bölgenin tüm yaz saati kurallarını ve tarihsel değişikliklerini içerir. Bir tarihi Europe/Berlin ile birleştirdiğinizde sistem, o tarihte yaz saatinin uygulanıp uygulanmadığını otomatik bilir.
| Bölge | IANA Adı | Yaz saati |
|---|---|---|
| İstanbul | Europe/Istanbul | Hayır (sabit UTC+3) |
| Londra | Europe/London | Evet |
| New York | America/New_York | Evet |
| Tokyo | Asia/Tokyo | Hayır |
| Hindistan | Asia/Kolkata | Hayır (UTC+5:30) |
Yaz Saati (DST) Tuzakları
Yaz saati, hata üreten en verimli kaynaktır. Dikkat edilecek üç senaryo:
- Kayıp saat: İlkbaharda saatler ileri alındığında, örneğin gece 02:00–03:00 arası "yok olur." Bu aralıkta bir saat oluşturursanız geçersiz olur.
- Tekrarlanan saat: Sonbaharda saatler geri alındığında 02:00–03:00 arası iki kez yaşanır. "01:30" hangi geçiş, belirsizdir.
- Sabit ofset varsayımı: "Saat farkını bir kez hesapla, sürekli kullan" mantığı, geçişten sonra bir saat hatalı sonuç verir.
Çözüm yine aynı: hesapları UTC üzerinde yapın. UTC yaz saati bilmez, dolayısıyla bu tuzakların hiçbiri UTC'de oluşmaz.
Saat Dilimleri Arası Planlama
Farklı ülkelerden katılımcıların olduğu bir toplantı planlarken her zaman tek bir mutlak anı referans alın. "Salı 15:00" yeterli değildir; "Salı 15:00 Europe/Istanbul" demelisiniz. Sistem bu anı UTC'ye çevirir, ardından her katılımcıya kendi yerel saatiyle gösterir.
Sınır ötesi planlamada saatlerin gün, hatta tarih atlayabileceğini unutmayın: İstanbul'da Çarşamba sabahı olan bir toplantı, Los Angeles'ta hâlâ Salı gecesidir. Hızlı dönüşümler için saat dilimi dönüştürücümüzü kullanabilir, ardından sonucu davetiyeye yazabilirsiniz.
İki Tarih Arasındaki Farkı Hesaplama
İki tarih arasındaki gün sayısını bulurken saatleri ortadan kaldırmak için yine UTC kullanın; aksi halde yaz saati, hesaba bir saat ekleyip "1 günden az" gibi yanlış sonuçlar üretebilir.
İş günü hesabı ise ayrı bir konudur: hafta sonlarını ve resmi tatilleri çıkarmanız gerekir. Bir teslim tarihini "10 iş günü sonra" diye verirken, takvim günleriyle iş günlerini karıştırmamaya dikkat edin. Bu tür hesaplar için tarih farkı aracımız gün, hafta ve iş günü cinsinden sonuç verir. Doğum tarihinden bugüne kadar geçen süreyi yıl-ay-gün olarak öğrenmek için yaş hesaplama aracını deneyebilirsiniz.
Zaman Damgalarını Saklama
Veri saklarken tek bir kurala sadık kalın: her zaman UTC, her zaman ISO 8601. ISO 8601 biçimi (2026-06-14T12:30:00Z) hem makine hem insan için okunaklıdır; sondaki Z harfi değerin UTC olduğunu söyler. Yerel saatleri ofsetsiz saklamak (2026-06-14 12:30) en sık yapılan ve en pahalı hatadır; çünkü o anın hangi dilime ait olduğu sonradan asla güvenilir biçimde bulunamaz.
En Sık Karşılaşılan Hatalar
- Tarihleri ofsetsiz, yerel saatle saklamak.
- Bir günü her zaman 86.400 saniye saymak (yaz saatinde değil).
- Saat dilimini sabit ofset olarak tutmak, IANA adı yerine.
- Sunucu ve istemci saatlerinin aynı dilimde olduğunu varsaymak.
- Kullanıcıya UTC saati ham haliyle göstermek.
Özet
Zaman karmaşık görünür ama disiplinle ehlileşir: UTC'de sakla ve hesapla, IANA adlarıyla dilimi belirt, kullanıcıya yerel saatle göster. Bu üç ilkeye sadık kaldığınızda yaz saati geçişleri, tarih atlamaları ve ofset karmaşası birer hata kaynağı olmaktan çıkar, sıradan birer detaya dönüşür.