Skip to content

Guide

Saat Dilimleri Arasında Planlama: Uzak Ekipler İçin Pratik Rehber

Takviminizde tekrarlayan toplantı yılda iki kez, iki farklı şekilde yanlışlanır ve kimse size söylemez.

By Published

Dağıtılmış ekipler aynı birkaç saat dilimi hatasına çılgınca zaman harcar: yılda iki kez bir saat kayan toplantılar, yanlış saatte gelen takvim davetleri, “herkes için sabah 9” ki böyle değil. Düzeltmeler küçüktür. Bunları yapmama maliyeti ortalamada yılda bir kaçırılan ürün lansmanıdır.

Sabit ofset değil, IANA bölgesi kullanın

IANA Saat Dilimi Veritabanı (genellikle tzdata veyazoneinfo olarak adlandırılır) dünyadaki saatlerin nasıl davrandığının yetkili kaynağıdır. Her bölge — Europe/Istanbul, America/Los_Angeles, Asia/Tokyo — bir kuraldır: o konum için UTC ofsetlerinin, YSS geçişlerinin ve siyasi değişikliklerin tam geçmişi.

GMT+3 veya UTC-5 gibi ham bir ofset birdeğerdir. Bazı yerler için yılın bazı dönemlerinde doğrudur, ancak YSS veya gelecekteki yasal değişikliklerden habersizdir. Türkiye 2016’da YSS’yi kaldırıp kalıcı olarak UTC+3’e geçti; İngiltere kışın UTC+0, yazın UTC+1’de kalır. Sabit ofset kullanan bir sistem bunu sessizce yanlış uygular.

YSS geçiş haftaları

Bir takvim uygulamasındaki saat dilimi hatalarını bulmanın en güvenilir yolu Mart’ın ikinci haftasına bakmaktır.

  • Amerika Birleşik Devletleri Mart’ın ikinci pazarı yaz saatine geçer, Kasım’ın ilk pazarında geri döner.
  • Avrupa Birliği Mart’ın son pazarında geçer, Ekim’in son pazarında geri döner.
  • İngiltere AB takvimine uyar (BST Mart’ın son pazarında başlar).
  • Avustralya (doğu eyaletleri) Ekim ve Nisan’da ters yönde değişir — Güney Yarıküre’dedirler.
  • Japonya, Çin, Hindistan, Afrika’nın çoğu, Güney Amerika’nın çoğu — YSS yok.

Pratik örtüşme pencereleri

ABD Doğusu ↔ Batı Avrupa

13:00-17:00 UTC.Bu yaklaşık Doğu saatiyle sabah 9-öğle 1 ve Londra’da öğleden sonra 2-6 / Orta Avrupa’da 3-7.

ABD Batısı ↔ Batı Avrupa

16:00-17:00 UTC. Bir saatlik pencere: sabah 9 Pasifik = öğleden sonra 5 Londra. Pek çok ekip bunu kabul eder ve haftalık tek bir senkronizasyon yapar, geri kalanını asenkron sürdürür.

Batı Avrupa ↔ Asya (Tokyo, Singapur, Seul)

08:00-10:00 UTC.Londra sabah 9 = Tokyo akşam 6. Londra için erken, Tokyo için günün sonu. Yinelenen toplantıları Pazartesi veya Salı’ya koyun.

ABD Batısı ↔ Asya

14:00-15:00 UTC. Sabah 7 Pasifik = Tokyo gece 11 (kış). Her iki taraf için de ağırdır. Bu bölgeleri eşleştiren ekiplerin çoğu canlı toplantıları tamamen atlar.

Takvim daveti tuzakları

TZID’siz ICS

iCalendar (ICS) formatı, bir toplantıyı iki şekilde kodlayabilir: UTC anı (DTSTART:20260601T130000Z) veya bir bölgeye bağlı yerel saat (DTSTART;TZID=America/New_York:20260601T090000). Tekrarlayan toplantılar her zaman TZID formunu kullanmalıdır.

Pratik öneriler

  • UTC + IANA bölgesi saklayın. Mutlak an için bir, oluşturucunun bölgesi için bir sütun. Görüntüleyicinin bölgesinde gösterin.
  • Tekrarlayan toplantı zamanlarını yerel saate göre değil UTC bandına göre seçin.
  • YSS geçişleri etrafında tekrarlayan toplantıları denetleyin.
  • Asenkron varsayılan seçeneğine geçin. En ucuz saat dilimi düzeltmesi daha az zorunlu toplantıdır.
  • Araçlarda IANA bölge adlarını kullanın. “PST” belirsizdir (Pakistan, Pasifik veya Pitcairn). America/Los_Angeles değildir.

Planlayıcıyı deneyin

Ekibinizin bölgelerini toplantı planlayıcımıza girin ve 24 saatlik günde yeşil/kırmızı örtüşme bantlarını görün. Tek seferlik dönüşümler için saat dilimi dönüştürücü keyfi tarih ve saat girişlerini karşılar.

Özet

Saat dilimi hataları tamamen önlenebilir. IANA bölge adlarını kullanın, UTC artı bölge saklayın, tekrarlayan toplantıları UTC bandına göre planlayın ve YSS geçiş haftaları etrafında doğrulayın. Dağıtılmış ekiplerde takvimle ilgili hayal kırıklığının çoğu bu dört kuraldan birinin ihlal edilmesine dayanır.

Frequently asked questions

'America/New_York', 'GMT-5'ten neden daha iyidir?
Çünkü America/New_York bir değer değil, bir kuraldır. EST, EDT ve aralarındaki geçiş tarihlerini — şu anda Mart’ın ikinci pazarı ve Kasım’ın ilk pazarı — kodlar. 'GMT-5' yılın yalnızca yarısında doğrudur. Sabit ofset kullanan her sistem her ilkbahar ve sonbaharda sessizce bozulur.
ABD ve AB saatleri neden aynı hafta sonu değişmiyor?
ABD, Mart’ın ikinci pazarı yaz saatine geçer; AB, Mart’ın son pazarında geçer. ABD/AB farkının normalden bir saat daha küçük olduğu bir-üç haftalık bir pencere oluşur. New York’ta sabah 9’luk toplantı normalde Paris’te saat 15’te oluyor ancak bu pencerede 14’te gerçekleşiyor.
ABD Doğu Kıyısı ile Batı Avrupa arasındaki en iyi örtüşme penceresi nedir?
13:00-17:00 UTC yıl boyunca işe yarar. Bu yaklaşık New York’ta sabah 9-öğle 1 arası ve Londra’da öğleden sonra 2-6 (CET 3-7) demektir.
ABD Batı ile Asya’yı kapsayan bir örtüşme var mı?
Çok az. Pasifik saati ile Tokyo yaklaşık bir saatlik örtüşme sunar (kışın sabah 7 PT = 23 JST, yazın gece yarısı). Dünya genelinde dağıtılmış ekiplerin çoğu bu eşleştirmenin yalnızca asenkron olduğunu ya da zorunlu senkronize zamanı geldiğinde yükü döndürdüğünü kabul eder.
Outlook ve Google Takvim neden aynı davette anlaşamıyor?
ICS dosyaları bir toplantıyı sabit bir UTC anı artı görüntüleme bölgesiyle ya da 'yüzen' yerel saatla kodlayabilir. Gönderenin ve alıcının istemcileri alanı farklı yorumladığında toplantı saat dilimi farkı kadar kayar.
Tüm iç planlamada UTC kullanmalı mıyım?
Depolama için evet, görüntüleme için hayır. Her etkinliği bir UTC anı artı oluşturucunun IANA bölgesi olarak saklayın. Her görüntüleyicinin yerel bölgesinde gösterin. YSS'siz 'UTC' görüntüleme bölgesinde tekrarlayan toplantı planlamayın — yılda iki kez kayar.

Related

Published May 31, 2026