Bir şehirde görünen saat, başka bir şehirdeki saatten yalnız sabit bir sayı kadar farklı olmayabilir. Bölgenin o tarihte kullandığı UTC ofseti, yaz saati geçişleri ve takvim günü birlikte önem taşır. Bu araç kaynak bölgenin yerel tarih ve saatinden gerçek anı bulur; aynı anın hedef bölgedeki tarih ve saatini gösterir. Kaynağın tarihini, saatini ve bölge adını birlikte girin.

Başlangıç örneği 11 Ekim 2026 saat 15.00 Europe/Istanbul girdisidir. Bu yerel gösterim UTC 12.00 anına karşılık gelir. Yüklü saat dilimi kurallarıyla aynı an America/New_York bölgesinde 11 Ekim saat 08.00 görünür. Sonuç yalnız 08.00 rakamından oluşmaz; 11 Ekim tarihi de dönüşümün parçasıdır. Başka tarihte veya başka bölge verisiyle farkın aynı kalacağını varsaymayın.

Yerel saat ile gerçek anı ayırın

Yerel tarih ve saat, bir duvar saatinde okunan takvim gösterimidir. Gerçek an ise dünya üzerindeki farklı bölgelerde başka rakamlarla gösterilebilen aynı zaman noktasıdır. İstanbul’da 15.00 ile New York’ta 08.00 aynı anda gerçekleşebilir. Bu iki saat arasında yedi saat yolculuk edilmiş olmaz; aynı an iki yerel gösterimle anlatılır. Form bir bölgedeki gösterimi diğerine çevirir, geçen süreyi ölçmez.

UTC satırı bu ilişkiyi açık tutar. Sonundaki Z işareti UTC gösterimini belirtir. Kaynak yerel saati doğrudan UTC kabul etmek, bölge ofsetini atlamak anlamına gelir. Örneğin İstanbul girdisindeki 15.00 için UTC satırı 12.00’dır; 15.00Z yazmak farklı bir gerçek an seçer. Sonucu bir toplantı davetine veya başka bir uygulamaya aktarırken yerel gösterimle UTC satırını birbirinin yerine kullanmayın.

Kaynak tarihini doğru bölgeden alın

Tarih alanı kaynak bölgenin yerel tarihidir. Hedefin takviminde ertesi gün başlamış olması, bu alana hedef tarihinin yazılmasını gerektirmez. Örneğin kaynakta 31 Aralık akşamı olan bir an, doğudaki bir hedefte 1 Ocak sabahı olabilir. Kaynak tarihini değiştirmeden dönüşümü yapın; hedefte oluşan yeni tarihi sonuçtan okuyun. Saatleri karşılaştırırken gün farkını ayrıca takip edin.

Kaynak tarih aralığı 1970–2100’dür. Bu sınır kaynak girdisine uygulanır; dönüşümün UTC veya hedef gösterimi sınırda 1969 ya da 2101 yılına geçebilir. Örneğin 1 Ocak 1970’in pozitif UTC ofsetli bir bölgedeki ilk saatleri, UTC takviminde 31 Aralık 1969’a karşılık gelebilir. Bu durumda tarihi zorla 1970’e taşımak doğru anı değiştirir. Araç komşu yılı sonuçta korur.

IANA bölge adı neden gereklidir?

Europe/Istanbul veya America/New_York gibi adlar yalnız bugünkü bir ofseti değil, adlandırılmış bölgenin tarihsel saat kurallarını temsil eder. Girdi tarihine göre hangi ofsetin geçerli olduğu bu kurallardan bulunur. Bir bölgenin mevcut farkını bütün geçmiş ve gelecek tarihlere uygulamayın. Özellikle yaz saati kullanan iki bölge, saatlerini aynı gün değiştirmek zorunda değildir; aralarındaki fark yıl içinde değişebilir.

Bu form desteklenen IANA adlarını, UTC’yi ve çalışma ortamının tanıdığı takma adları kullanır. +03:00 gibi yalnız sayısal sabit ofset yazımı kabul edilmez. Böyle bir yazım bir bölgenin geçmiş veya gelecekteki geçişlerini anlatmaz. UTC kullanmak istiyorsanız UTC yazın; Türkiye için tarihli bir dönüşüm yapıyorsanız Europe/Istanbul kullanın. Bölge adının tanınmaması, tarayıcının veri desteğiyle ilgili de olabilir; hata ilgili kaynak veya hedef alanında gösterilir.

Normal bir saatin tek eşleşmesi vardır

Saat değişiminin dışında kalan sıradan bir yerel tarih ve saat genellikle tek bir UTC anıyla eşleşir. Bu durumda ilk veya ikinci gerçekleşme seçiminin sonucu değiştireceği ikinci bir aday bulunmaz. Başlangıç örneğinde 15.00 İstanbul için tek eşleşme UTC 12.00’dır. Sonuç bölümündeki eşleşen UTC anı sayısı bir, uygulanan an seçimi tek eşleşme olarak görünür.

Kaynak ve hedefi aynı bölge seçmek de bu ilkeyi değiştirmez. Tek eşleşmeli bir saatte hedef yerel gösterim kaynakla aynı olur. Ancak kaynakta iki kez yaşanan bir saat seçildiğinde hedefin aynı bölge olması belirsizliği ortadan kaldırmaz. Aynı yerel saat iki farklı gerçek anı gösterir; UTC satırları farklıdır. Önce gerçek an açıkça belirlenir, sonra hedef gösterimi oluşturulur.

Saat ileri alındığında bir boşluk oluşabilir

Saatler ileri alındığında bazı yerel saatler hiç yaşanmaz. Örneğin New York’ta 10 Mart 2024 tarihindeki 02.30, ilkbahar geçişinin atlanan aralığındadır. Bu girdiye uygun gerçek UTC anı bulunmaz. Araç zaman alanını işaretler ve sonuç üretmez. Girdiğiniz 02.30’u haber vermeden 03.30’a veya 01.30’a dönüştürmek yerine geçerli bir tarih ve saat seçmenizi ister.

Formdaki ilk ve ikinci gerçekleşme seçimi bu boşluğu gidermez. Üç seçenekte de atlanan saat reddedilir. Bazı tarih ve saat yazılımları boşlukta önceki ya da sonraki ofsetle saati kaydıran seçenekler sunabilir. Burada alanın amacı yalnız iki kez yaşanan saati ayırmaktır; bu kaydırma davranışı kullanılmaz. Başka uygulamadaki aynı adlı seçeneğin boşluk için de aynı sonucu vereceğini varsaymayın.

Saat geri alındığında iki gerçek an olabilir

Saatlerin geri alınması bazı yerel gösterimleri tekrar ettirir. New York’ta 3 Kasım 2024 saat 01.30 iki kez yaşanır. İlk gerçekleşme UTC 05.30, ikinci gerçekleşme UTC 06.30’dur. Kaynak saat rakamları aynı olsa da bunlar bir saat arayla iki ayrı andır. Varsayılan seçim hesaplamayı durdurur; ilk veya ikinci anı açıkça seçmeniz gerekir.

İlk gerçekleşen ve ikinci gerçekleşen ifadeleri UTC sırasını anlatır. Hedefte daha küçük saat rakamı görünmesi, daha erken anı belirlemek için yeterli değildir; hedefte tarih değişebilir veya saat tekrar yaşanabilir. Araç adayları UTC sırasına dizer ve seçilen anı tabloda işaretler. New York örneğinde hedef İstanbul olduğunda ilk an 08.30, ikinci an 09.30 olur. Kaynak girdisi ikisinde de 01.30’dur.

Geçişin bir saat olduğunu varsaymayın

Her saat değişimi bir saatlik değildir. Australia/Lord_Howe bölgesinde 7 Nisan 2024 saat 01.45 iki kez yaşanır; iki gerçek anın arası 30 dakikadır. İlk aday 6 Nisan UTC 14.45, ikinci aday UTC 15.15’tir. İkinci an seçilip hedef UTC yapıldığında 6 Nisan 15.15 sonucu alınır. Kaynağın tarihi 7 Nisan olduğu için gün farkı eksi birdir.

Benzer biçimde ileri geçişin atladığı aralık da her yerde aynı uzunlukta olmaz. Lord Howe için 6 Ekim 2024 saat 02.15 geçerli bir yerel saat değildir. Sayısal bir saate alışılmış bir saat ekleyerek çözüm üretmek doğru davranış sayılmaz. Bölgenin girdi tarihindeki kuralı ve kaynak yerel saate gerçekten uyan adaylar kontrol edilmelidir. Sonuçtaki aday tablosu bu ayrımı görmenizi sağlar.

Bir takvim gününün tamamı da atlanabilir

Sivil saat değişimleri yalnız yaz saati uygulamasından doğmaz. Tarih çizgisiyle ilişkili bir değişiklik bütün yerel günü atlatabilir. Pacific/Apia bölgesinde 30 Aralık 2011 tarihindeki yerel saatler böyle bir boşluğa örnektir. O gün için 12.00 yazmak sıradan bir öğle saati oluşturmaz. Araç bu girdiyi reddeder; 29 veya 31 Aralık’a sessizce taşımaz.

Böyle bir durumda takvim uygulamasının gösterdiği tarihi ve etkinliğin gerçek yerel planını yeniden kontrol edin. İlk veya ikinci an seçimi olmayan bir günü var etmez. Tekrarlanan toplantı, otel girişi veya ulaşım programı için özel bir yeniden planlama kuralı gerekiyorsa bu ayrı bir işlemdir. Bu form yalnız verilen tek yerel tarih ve saatin gerçek bir ana karşılık gelip gelmediğini çözer.

Saniyeli tarihsel ofsetleri koruyun

Girdi saatinde yalnız saat ve dakika bulunur; saniye sıfır kabul edilir. Ancak tarihsel bir bölgenin UTC ofseti saniye içerebilir. Örneğin Africa/Monrovia bölgesinde 1 Ocak 1970 saat 00.00, UTC 00.44.30’a karşılık gelir. Bu durumda hedef veya UTC sonucundaki 30 saniye bir hesap hatası değildir. Kaynağın dakika sınırı, UTC’nin dakika sınırıyla aynı olmak zorunda değildir.

Sonuç saatinde saniyelerin gösterilmesi bu tür ayrımları korur. Saniyeyi silip 00.44 yazmak aynı gerçek anı tam olarak aktarmaz. Buna karşılık kullanıcı saniyeli kaynak saat giremez; saat alanı 00:00–23:59 biçimindedir. Artık saniye veya 23:59:60 girişi desteklenmez. Bu dönüşüm modeli sivil tarih gösterimleri içindir; yüksek hassasiyetli zaman ölçümü veya fiziksel süre standardı hizmeti olarak kullanılmaz.

Tarayıcı verisi ile güncel resmî karar aynı değildir

Dönüşümde tarayıcının yüklü saat dilimi verisi kullanılır; her hesapta internetten yeni kural indirilmez. İşletim sistemi ve tarayıcı güncellemeleri farklı zamanda geldiği için iki cihaz aynı yeni tarih için farklı sonuç gösterebilir. Bölge adının tanınması da verinin en son kararları içerdiğini tek başına kanıtlamaz. Yeni alınmış bir resmî karar varsa kullanılan uygulamanın güncelliğini ayrıca kontrol edin.

IANA veri tabanı geçmiş ve öngörülen gelecek kurallarını düzenler; hükümetler ofset veya yaz saati kararlarını değiştirebilir. Bu nedenle 2100 yılına ait bir sonuç üretilebilmesi, o tarihteki yasal saatin kesinleştiğini anlatmaz. Geçmiş örneklerle doğru dönüşüm yapılması da gelecekte değişiklik olmayacağını kanıtlamaz. Uçuş, sınav, hukuki süre veya kritik toplantı için ilgili kurumun güncel tarih ve saat bildirimini esas alın.

Sonucu üç satırla birlikte aktarın

Paylaşılacak bir etkinlik için kaynak yerel tarih ve saat, bölge adı ve seçilen UTC anını birlikte saklamak yararlıdır. Hedef gösterimi de tarihini içermelidir. Yalnız 01.30 yazılması, geri geçişte hangi gerçekleşmenin istendiğini anlatmaz. Araç tablosundaki seçilen an ve UTC satırı bu eksikliği giderir; gerekli bağlamı bir davet veya notta açıkça belirtmenize yardım eder.

Bu form tekrarlanan etkinlikler için bütün yılın takvimini üretmez. Her pazartesi 15.00 yerel toplantı ile her hafta aynı UTC anını esas alan toplantı farklı kurallara sahip olabilir. Tek bir örnekte iki gösterimin eşitlenmesi, sonraki haftalarda da aynı farkın süreceğini göstermez. Başka tarihe plan yaparken o tarihi yeniden hesaplayın ve özellikle iki bölgenin geçiş haftalarında sonuç tarihini kontrol edin.

Dönüşümü küçük kontrollerle doğrulayın

Sonuçta önce kaynak gösteriminin girdiğiniz tarih ve saate uyduğunu kontrol edin. Ardından UTC satırını ve kaynak ofsetini birlikte okuyun. Kaynak UTC+03.00 iken yerel 15.00 için UTC 12.00 beklenir; hedef UTC−04.00 olduğunda aynı UTC anı yerel 08.00 olur. Bu kontrol aynı tarihli basit örnekte kolaydır; gün değişiminde takvim tarihlerini de hesaba katmanız gerekir. Yalnız saat rakamlarını çıkararak ofset işaretini belirlemeyin.

Hedef bölgenin ofseti eksi olması, hedefin her durumda kaynak takviminde önceki günde bulunacağı anlamına gelmez. Günün hangi saatinde olduğunuz ve kaynağın ofseti de sonucu etkiler. Örneğin UTC öğlen saatlerinde negatif ofsetli bir hedef hâlâ aynı takvim gününde kalabilir. Sonuçtaki gün farkı bu nedenle ayrıca hesaplanır. Eksi bir, sıfır veya artı bir değerini ileri ya da geri yolculuk süresi gibi yorumlamak yerine hedef tarihinin kaynak tarihine göre konumu olarak okuyun.

İki aday bulunan bir örnekte ilk ve ikinci seçimi art arda deneyerek UTC satırlarını karşılaştırabilirsiniz. Kaynak yerel gösterimin sabit kaldığını, seçilen gerçek anın değiştiğini ve hedefin buna göre güncellendiğini görürsünüz. Bu karşılaştırma geçişin uzunluğunu görünür kılar; her seferinde bir saat beklemek yerine tablodaki iki gerçek anı kullanın. Atlanan saat örneğinde ise böyle iki geçerli aday bulunmaz; sonuç üretilememesi aynı belirsizlik türü değildir. Önce geçerli kaynak saatini belirlemek gerekir.