Zaman dilimleri ve hassasiyet

1) Temel prensipler

Taşıma ve depolama olarak UTC. Tüm sunucu zaman damgaları ve sıralama anahtarları UTC'dedir. Yerel "duvar" zamanına dönüştürme - kenarda (kenar/UI) veya özel olarak ayrılmış bir biçimlendirme hizmetinde.
Bölge ≠ ofset. 'Avrupa/Kiev' sadece 'UTC + 02:00' değildir: kurallar zamanla değişir. IANA kimliklerini (tzdb) "+ 03:00'değil, kullanıcı/nesne profilinde saklayın.
Açık saat ayrımı.

Duvar saati (insan zamanı, DST'ye tabi).
UTC saati (evrensel ölçek).
Monotonik saat (süreleri ve zaman aşımlarını ölçmek için). Bir duvar saatindeki zaman aşımlarını asla hesaplamayın.
Idempotency ve zaman titreme toleransı. Sistemler doğru küçük NTP/ofset atlar hayatta kalmalıdır.

2) Veri modeli ve API sözleşmeleri

Olaylar: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), opsiyonel olarak 'wall _ time' (local with offset at creation).
Dönemler: UTC'de yarı kapalı aralıklar '[başlangıç, bitiş)' kullanın; İnsan tarafından okunabilir programlar için, orijinal ifadeyi + bölge tutun.
Yinelenen kurallar: RRULE/cron eşdeğeri + IANA bölgesi olarak serileştirin. Planlamayı DST'yi anlayan bir motora devredin.
API'deki zaman biçimi: ISO 8601/RFC 3339, açık 'Z' veya ofset, örneğin '2025-10-31T17: 00: 00Z'. Kayan çizgileri kaydırmadan geçmeyin.
Sürüm oluşturma: zaman iş kurallarını değiştirmek (örneğin, bir ülkeyi sabit UTC + 1'e geçirmek), yapılandırmaların taşınması ve programların yeniden hesaplanmasıdır; serbest bırakma şemalarında düşünün.

3) Yaz Saati (DST): belirsizlikler ve eksiklikler

Yerel zamanlarda çoğaltılır. Sonbaharda, yerel "02:30" iki kez olabilir. Bölgedeki planlayıcı '2025-10-26T02: 30 + 03've' 2025-10-26T02: 30 + 02 'arasında ayrım yapmalıdır.
Yerel zamanları kaçırdım. İlkbaharda, dakika aralıkları "atlama" (örneğin, '02: 00-03: 00' mevcut değildir). Planlayıcı stratejiyi belirlemelidir: "03:00'e geçin," mümkün olan en kısa sürede "atlayın veya çalıştırın.
Öneri: işi "yerel kural + bölge'olarak saklayın ve seçilen politikayı DST'de sabitleyerek gerçek örnekleri önceden UTC'de (yuvarlanma penceresi) gerçekleştirin.

4) Sıçrama saniye и zaman smear

İkinci sıçrama. Fazladan bir saniye bazen UTC'ye eklenir. Çoğu iş süreci 23:59:60'ı "görmemelidir".
Karalama. Bazı ortamlar, atlamadan kaçınmak için ayarı pencere başına (örneğin, 12 saat ±) yavaşça dağıtır.
Uygulama: tüm küme (NTP/smir) için tek bir zaman politikası üzerinde anlaşın, meta verilerde oturum açın ve çalışma kitabında saklayın.

5) Planlayıcılar ve cron desenleri

"Basit cron" tehlikesi. Klasik cron, DST ve IANA bölgelerini bilmiyor. Zamanlamanın bölgeye bağlı olduğu motorları kullanın (Kuvars sınıfı, bulut Zamanlayıcı hizmetleri, denetleyici/yönetim yoluyla bölge ile Kubernetes CronJob).
Programları gerçekleştiriyorum. Güvenilirlik için, bir sonraki N'yi UTC'de (örneğin, 7-30 gün boyunca) gerçekleştirin, imleci saklayın ve DST'de politikayı belirleyin.
Görevlerin idempotensi. Ключ veri tekilleştirme: '(job_id, scheduled_at_utc)'; Yeniden başlatma yan etkileri çoğaltmamalıdır.
Saat kayması. Uzun duraklamalar/olaylar için, yakalamak veya atlamak için karar verin. İş başına yapılandır.

6) Protokollerde ve kuyruklarda geçen süre

Etkinlik otobüsleri (Kafka/Pulsar). 'Event _ time've' ingest _ time 'ayrı ayrı saklayın. Geriye dönük tahsisler için 'event _ time' kullanın.
Idempotent tüketiciler. Yeniden teslim ederken, toplu işlemdeki ofset yerine olay tuşuna ve'olay _ saati'ne odaklanın.
Sıralama ve pencereler. "24 saat yerel mağaza saati" pencerelerini belirli bir tarih için belirli bir bölgenin yerel kurallarından elde edilen UTC aralıkları olarak hesaplayın.

7) Günlükler, izler, metrikler

Birleştirilmiş saat dilimi standardı: UTC'deki tüm teknik günlükler ve metrikler ('Z'yi gösterir). Panolarda görüntüleme - kullanıcı için yerelleştirilmiş.
Trace - Monotonik bir saatte 'trace _ start _ utc', 'duration _ ms'yi geçin. Asla "duvar" zaman damgalarını çıkarmayın.
İşletme raporları: Etki alanı bölgesinde bir "gün" oluşturun (örn. UTC yerine Fransız vergisi için 'Avrupa/Paris'). Belge açıkça.

8) Kullanıcı profilleri ve içeriği

Профиль: 'preferred _ timezone' (IANA), 'preferred _ locale', 'currency', 'week _ start' (Mon/Sun).
Çok bölgeli varlıklar: ekipler/kuruluşlar için, katılımcının kişisel bölgesinden bağımsız olarak bir "etki alanı bölgesi" (örneğin, bir mağaza/tüzel kişilik) depolayın.
Bildirimler: Kullanıcı bölgesinde "sessiz saatleri" hesaplayın; DST güvenliği ile UTC penceresinden gönderin.

9) Anti-desenler

Ofset/zone olmadan yalnızca yerel saati depolayın.
IANA tanımlayıcı yerine sabit flaş ofseti '+ hh: mm'.
İki "duvar" zaman damgasının farkı ile süreyi hesaplayın.
Bölge/DST desteği olmadan cron tarafından planlayın.
Standart bir yerel bölge gerektirdiğinde UTC'de "günden güne" analiz yapın.
Bölge kurallarının değişmezliğini varsayalım (ülkeler zaman politikasını değiştirir).

10) Zaman testi

Kontrollü saatler. Deterministik testler için "saati" koda (Clock/TimeProvider) enjekte edin.

• Gün ışığından yararlanma saati (dublajlar/atlamalar) değişir.
• Kullanıcıyı bölgeler arasında taşıyın ('preferred _ timezone' öğesini değiştirin).
• Tzdb'de kural değişikliği (temel güncelleme - regresyon testleri).
• NTP ofsetleri, olayların gecikmeli teslimatı.
• Bulanık testler. Rastgele bölgeler, tarihler, formatlar; Referans kitaplığı ile karşılaştırma.

11) Gözlemlenebilirlik ve çalışma

Uyarılar: NTP yanlış hizalama, tzdb güncelleme gecikmesi, DST ile "yerine getirilmemiş" cron görevlerinin patlamaları.
Panolar: olayların bölgelere/yerel günlere göre dağılımı; catch-up/skip sayaçları.
Runbook: Bir yargı alanındaki zaman kurallarını değiştirme prosedürleri; Program sahipleriyle iletişim kuran tzdb güncelleme sırası.

12) Uygulama kalıpları

Zaman Normalleştirme Geçidi. RFC 3339 UTC'ye gelen zamanları normalleştiren ince bir hizmet, bölgeleri (IANA) doğrular ve bağlamı tamamlar.
Yerel Gün Oluşturucu. DST'yi dikkate alarak "yerel gün've bölgeden tam UTC sınırları" [start _ utc, end_utc) "oluşturan bir kütüphane/hizmet.
Materializer'ı programla. Kuralları "yerel ifade + bölge'olarak saklayan bir zamanlayıcı, UTC'de gelecekteki örnekleri gerçekleştirir ve çakışmaları/ihmalleri yönetir.
Çift Zamanlı Olaylar. 'Occurred _ at _ utc', 'wall _ time _ local', 'timezone' alanlarına sahip olaylar. Yerel UI, sistemler için UTC yerine geçer.

13) Mimar kontrol listesi

1. UTC her yerde saklanıyor mu?
2. İşletmenin bir IANA bölgesi ve etki alanı veri politikası var mı?
3. Zamanlayıcı DST'yi anlıyor ve UTC'deki örnekleri gerçekleştiriyor mu?
4. Günlükler/metrikler - UTC'de; Raporlar - etki alanında mı?
5. Zaman aşımları/geri çekilmeler - monotonik bir saatte?
6. Tzdb güncellemesi otomatik ve izlenir mi?
7. Testler kural değişikliklerini, çift/cevapsız dakikaları kapsar mı?

14) Mini tarifler (pseudocode)

Yerel "iş gününü" UTC aralığına dönüştürme

function localDayToUtcInterval(dateLocal, tz):
startLocal = combine(dateLocal, 00:00) in tz endLocal  = startLocal + 1 day startUtc  = toUTC(startLocal) // учитывает DST endUtc   = toUTC(endLocal)
return [startUtc, endUtc)

Yinelenen Bir Zamanlamanın Gerçekleştirilmesi

inputs: rrule, tz, windowStartUtc, windowEndUtc for each localOccurrence in expand(rrule, tz, [windowStartUtc, windowEndUtc] projected to tz):
emit occurrence { scheduled_at_utc = toUTC(localOccurrence), tz }

Idempotent görev başlangıç tuşu

dedupe_key = hash(job_id + scheduled_at_utc.toString())

15) Güvenlik ve uyumluluk

Denetim: Kullanıcı iddialarını ("11: 00 Lima'dan önce söz verildi") sunucu kronolojisiyle uzlaştırmak için hem zaman projeksiyonlarını (UTC hem de yerel) saklayın.
Düzenleyici: Raporlama dönemleri gerekli bölgelerde oluşturulur (vergiler, sorumlu oyun limitleri, pazarlama kısıtlamaları "saat başı").
Gizlilik: saat dilimi - kişisel ayarlar, ancak verileri doğru bir şekilde tanımlamamak; Ortak gizlilik politikaları dahilinde süreç.

Sonuç

"Zaman hassasiyeti" tarih biçimi ile ilgili değil, sorumluluğun mimari sınırları ile ilgilidir: nerede saklanacağı, nerede dönüştürüleceği, nasıl planlanacağı ve doğruluğun nasıl kanıtlanacağı. UTC birleştirme, açık IANA bölgeleri, yetkili zamanlayıcılar, çift zaman damgaları ve monotonik saatler, zamanı bir olay kaynağından öngörülebilir bir altyapı hizmetine dönüştürür.

• GeoDNS ve coğrafi yönlendirme; Yük dengeleme; Olayların zaman içinde gözlemlenebilirliği; Cron desenleri ve program materyalizasyonu; Bölgesel kısıtlamalar ve yerel raporlama günleri.