Saat Dilimleri Nasıl Çevrilir: UTC, IANA ve Yaz Saati Tuzağı
Bir saati başka bir saat dilimine çevirmek çoğu zaman iki sayıyı toplayıp çıkarmak kadar basit görünür, ama tek başına “İstanbul ile New York arasında yedi saat var” bilgisi her zaman yetmez. Yaz saati uygulaması ülkeden ülkeye farklı tarihlerde başlayıp bittiği için, yılın belirli haftalarında bu alışılmış fark bir saat kayar. Çoğu rehber de bu birkaç haftalık kayma dönemini hiç anlatmaz, oysa gerçek tarih ve saatlerle bakınca çok da karmaşık değil.
UTC, IANA ve yaz saatinin karıştırdığı denklem
Her saat dilimi, UTC (Eşgüdümlü Evrensel Zaman) adlı ortak referansa göre tanımlanan sabit ya da mevsimlik bir kaymadır. İstanbul yılın 365 günü UTC+3’tür. Londra kışın UTC+0 (GMT), yazın UTC+1 (BST) olur. New York da kışın UTC-5 (EST), yazın UTC-4 (EDT) arasında gidip gelir. Bilgisayarlar ve telefonlar bu kaymaları tek tek ezberlemez, “Europe/Istanbul” ya da “America/New_York” gibi isimlerle tanımlanan IANA saat dilimi veritabanını kullanır. Bu veritabanı her bölgenin yaz saatine hangi tarihte girip çıktığını yıl yıl tutar ve kurallar değiştiğinde güncellenir.
Karmaşa tam burada başlıyor: ABD ile AB/İngiltere yaz saatine aynı tarihte geçmiyor, aynı tarihte de çıkmıyor. 2026’da ABD ve Kanada 8 Mart Pazar günü yaz saatine geçip 1 Kasım Pazar günü çıkarken, AB ve İngiltere 29 Mart Pazar günü geçip 25 Ekim Pazar günü çıkıyor. Bu iki takvim arasındaki üç haftalık ve bir haftalık boşluklarda, kafanızdaki “alışılmış fark” birdenbire yanlış çıkar, çünkü Atlantik’in iki yakası aynı anda farklı mevsim saatinde kalır.
Örnek: İstanbul’dan Londra ve New York’a bir toplantı saati
İstanbul merkezli bir ekibin her hafta saat 17:00’de (Türkiye saatiyle) Londra ve New York’taki iş ortaklarıyla video görüşmesi yaptığını düşünelim. Bu saatin karşı taraftaki karşılığı, yılın hangi döneminde olduğunuza göre değişir. Türkiye kendi saatini hiç değiştirmediği için kayma her zaman karşı tarafta olur.
Yılın büyük bölümünde, yani hem ABD hem de AB/İngiltere kendi yaz saatlerindeyken (yaklaşık 29 Mart ile 25 Ekim arası):
| Şehir | Saat dilimi | Yerel saat |
|---|---|---|
| İstanbul | UTC+3 (TRT) | 17:00 |
| Londra | UTC+1 (BST) | 15:00 |
| New York | UTC-4 (EDT) | 10:00 |
İstanbul ile Londra arasında 2 saat, İstanbul ile New York arasında 7 saat fark vardır ve bu farklar yaz saati boyunca sabit kalır.
Şimdi aynı toplantıyı 8 Mart ile 29 Mart 2026 arasındaki üç haftalık pencerede düşünün. ABD o tarihte yaz saatine çoktan geçmiştir, ama Londra henüz kış saatindedir (GMT):
| Şehir | Saat dilimi | Yerel saat |
|---|---|---|
| İstanbul | UTC+3 (TRT) | 17:00 |
| Londra | UTC+0 (GMT) | 14:00 |
| New York | UTC-4 (EDT) | 10:00 |
New York’taki saat değişmedi, çünkü New York zaten yaz saatine geçmişti. Ama Londra’daki saat bir önceki tabloya göre bir saat geri kaydı: 15:00 yerine 14:00. Toplantıyı önceden hesaplayıp takvime “Londra saatiyle 15:00” diye yazan biri, bu üç haftalık pencerede toplantıya bir saat geç kalır. Aynı kayma 25 Ekim ile 1 Kasım 2026 arasında da tekrarlanır, bu sefer ters yönde: Londra kış saatine dönerken New York henüz yaz saatinde kalır ve fark yine 5 saat yerine 4 saat olur.
Kendi saatlerinizi çevirin
Dönüştürülen saat
Sık yapılan hatalar
Yaz saati geçiş tarihlerinin her yerde aynı olduğunu varsaymak. Yukarıdaki örnekte gösterildiği gibi, ABD ile AB/İngiltere yaklaşık üç hafta arayla yaz saatine girip çıkıyor. Bir toplantıyı ocak ayında, yani hiçbir geçiş penceresinin dışında ayarlayıp saatleri elle hesaplarsanız, mart ve ekim aylarındaki bu kısa pencerelerde hesabınız bir saat kayar. Modern takvim uygulamaları (Google Takvim, Outlook gibi) bu farkı otomatik olarak düzeltir, çünkü davetiyeyi mutlak UTC zamanı olarak saklar ve her katılımcı için kendi diliminde yeniden hesaplar. Ama bir sohbet uygulamasına düz metin olarak yazılan “Türkiye saatiyle 17:00” gibi bir not kendini hiçbir zaman güncellemez.
GMT ile UTC’yi aynı şey sanmak. Günlük konuşmada ikisi birbirinin yerine kullanılır ve pratikte saniyeler mertebesindeki fark çoğu kullanıcıyı ilgilendirmez. Ama GMT aslında Londra’nın kış saati dilimidir, yazın Londra GMT’de değil BST’dedir. “Saat GMT ile 15:00” demek, yazın gerçekte “UTC ile 14:00” anlamına gelir. Bu ayrımı gözden kaçırmak, yukarıdaki tabloda gösterilen türden bir saatlik kaymaya yol açabilir.
Türkiye’nin yaz saati uygulamadığını unutmak. Türkiye 2016’dan beri yılın her günü sabit UTC+3 kullanıyor, yaz saati uygulamasına hiç geçmiyor. Bu yüzden İstanbul’daki bir ekip için değişen taraf her zaman karşı taraf, yani Londra ya da New York oluyor. Kendi saati hiç kaymadığı için bazen karşı tarafın da kaymadığı varsayılıyor.
Gün değişimini gözden kaçırmak. Saat farkı büyüdükçe, çevrilen saat bir sonraki takvim gününe kayabilir. İstanbul’da akşam 22:00’de planlanan bir görüşme, Tokyo’da (UTC+9) aynı günün gecesine değil, ertesi günün 04:00’üne denk gelir. Bunu görmeden “aynı gün, farklı saat” varsayımıyla davetiye gönderenler, karşı tarafı yanlış takvim gününe çağırmış olur; bu yüzden bir saat dilimi çevirme aracının gün değişimini +1 gün / −1 gün gibi açıkça göstermesi önemlidir.
Sıkça sorulan sorular
Saat dilimi çevirirken en çok hangi hata yapılır?
En sık yapılan hata, ABD ile AB/İngiltere’nin yaz saatine aynı tarihte geçtiğini varsaymaktır. Oysa 2026’da ABD 8 Mart’ta, AB/İngiltere ise 29 Mart’ta yaz saatine geçiyor; aradaki üç haftalık pencerede alışılmış saat farkı bir saat değişir, aynı durum 25 Ekim ile 1 Kasım arasında ters yönde tekrarlanır.
UTC ile GMT arasındaki fark nedir?
UTC, dünya genelinde kullanılan sabit bir zaman referansıdır ve hiç değişmez. GMT ise Londra’nın kış saati dilimidir. Kışın UTC ile aynı değeri taşır, ama yazın Londra BST’ye (UTC+1) geçtiği için GMT ile UTC aynı anda farklı saatleri gösterir.
Türkiye neden yaz saati uygulamıyor?
Türkiye 2016 yılında yaz saati uygulamasını kaldırdı ve o tarihten beri yılın tamamında sabit UTC+3 dilimini kullanıyor. Bu yüzden Türkiye’den yurt dışıyla yapılan görüşmelerde saat kayması her zaman karşı taraftaki yaz saati geçişinden kaynaklanır.
Saat dilimi çevirme aracı bu hesaplamaları nasıl yapıyor?
Araç, tarayıcınızın yerleşik Intl.DateTimeFormat API’sini ve IANA saat dilimi veritabanını kullanarak seçtiğiniz tarih ve saati hedef saat dilimine çevirir, gün değişimi varsa (+1 gün / −1 gün) bunu da ayrıca gösterir. Böylece yaz saati geçiş tarihlerini elle takip etmenize gerek kalmaz.