Yaz saati (DST) hatalarını önlemek için pratik kurallar: temiz zaman damgaları saklayın, doğru yerel zamanı gösterin ve kullanıcıların doğrulayabileceği güvenilir raporlar oluşturun.
Zaman hataları, insanların UTC'de yaşamadığı için çıkar. İnsanlar yerel saatte yaşar ve yerel saatler ileri atılabilir, geri alınabilir veya yıllar içinde kuralları değişebilir. İki kullanıcı aynı anı farklı saatlerle görebilir. Daha kötüsü, aynı yerel saat iki farklı gerçek ana işaret edebilir.
Yaz saati (DST) hataları genellikle yılda sadece iki kez ortaya çıkar, bu yüzden gözden kaçabilir. Geliştirmede her şey düzgün görünür, sonra gerçek bir müşteri geçiş haftasonunda randevu ayarlar, mesai girer veya rapora bakar ve bir şeyler yanlış görünür.
Ekipler genellikle önce birkaç modeli fark eder: planlanmış öğelerin kaybolduğu veya kaydığı “kayıp saat”, günlüklerin veya uyarıların çift göründüğü, ve bir “gün”ün 23 veya 25 saat olması nedeniyle günlük toplamların kaydığı durum.
Bu sadece geliştirici sorunu değildir. Destekte “uygulamanız toplantı zamanımı değiştirdi” diye biletler gelir. Finans günlük gelirlerin uyuşmadığını görür. Operasyon neden gece işler iki kez çalıştı veya atlandı diye merak eder. Hatta “bugün oluşturuldu” filtreleri farklı bölgelerdeki kullanıcılar arasında anlaşamayabilir.
Hedef sıkıcı ama güvenilir: zamanı anlamını kaybettirmeyecek şekilde saklayın, yerel zamanı insanların beklediği biçimde gösterin ve tuhaf günlerde bile doğru kalan raporlar oluşturun. Bunu yaptığınızda işin her bir parçası sayılara güvenebilir.
İster özel kodla ister AppMaster gibi bir platformla inşa edin, kurallar aynıdır. Orijinal anı koruyan zaman damgaları ve o anın nasıl göründüğünü açıklayacak yeterli bağlam (kullanıcının zaman dilimi gibi) istersiniz.
Çoğu DST hatası “bir an” ile “saatin gösterdiği” şeyi karıştırmamızdan kaynaklanır. Bu fikirleri ayrı tutun, kurallar çok daha basit olur.
Kısa terimler:
Bir ofset bir zaman dilimi ile aynı şey değildir. -05:00 sadece tek bir andaki UTC farkını söyler. Yaz aylarında -04:00 olup olmayacağını veya yasaların gelecek yıl değişip değişmeyeceğini söylemez. Bir zaman dilimi adı bunu söyler, çünkü kuralları ve geçmişi taşır.
DST ofseti değiştirir, temel zaman damgasını değil. Olay hâlâ aynı anda oldu; sadece yerel saat etiketi değişir.
İki durum çoğu karışıklığa neden olur:
Bir destek bileti sonbahar tekrarında “01:30” oluşturulduysa, olayları doğru sıraya koymak için zaman dilimi ve kesin an (UTC zaman damgası) gerekir.
Çoğu DST hatası biçimlendirme sorunu değil, veri sorunudur. Saklanan değer belirsizse, sonraki her ekran ve rapor tahmin yapmak zorunda kalır ve bu tahminler uyuşmaz.
Bir şey belirli bir anda olduysa (ödeme alınması, bilet cevabı, mesai başlangıcı), zaman damgasını UTC olarak saklayın. UTC ileri veya geri atlamaz, bu yüzden DST değişikliklerinde sabit kalır.
Örnek: Bir New York destek görevlisi saat değişim gününde yerel saatle 09:15’te yanıt veriyorsa, UTC anını saklamak, bir Londra kullanıcısı daha sonra konuyu incelediğinde yanıtın doğru sırada kalmasını sağlar.
Zamanı insan dilinde göstermeniz gerektiğinde kullanıcının veya yerin zaman dilimini bilmeniz gerekir. Bunu America/New_York veya Europe/London gibi IANA zaman dilimi kimliği olarak saklayın, “EST” gibi belirsiz etiketler yerine. Kısaltmalar farklı şeyler anlamına gelebilir ve yalnızca ofsetler DST kurallarını kapsamaz.
Basit bir desen: olay zamanı UTC olarak, ayrıca kullanıcıya, ofise, mağazaya veya cihaza iliştirilmiş ayrı bir zaman dilimi kimliği.
Doğum günleri, “5’inde yenilenir” ve “fatura vadesi” gibi bazı değerler gerçek anlar değildir. Bunları tarih alanı olarak saklayın. Zaman damgası olarak saklarsanız, saat dilimi dönüşümleri onları bir önceki veya sonraki güne taşıyabilir.
“2026-03-08 02:30” veya “9:00 AM” gibi zamanları zaman dilimi olmadan kaydetmekten kaçının. Bu zaman DST geçişlerinde belirsiz (iki kez oluşan) veya imkansız (atlanan) olabilir.
Yerel giriş kabul etmeniz gerekiyorsa, hem yerel değeri hem de zaman dilimi kimliğini saklayın ve gerçek olay anı için UTC'ye dönüştürün.
Birçok DST hatası bir kayıt türünün başka gibi muamele görmesinden kaynaklanır. Bir denetim kaydı, takvim toplantısı ve bordro kesintisi hepsi “tarih ve saat” gibi görünür ama doğru kalmaları için farklı verilere ihtiyaç duyarlar.
Geçmiş olaylar için (zaten olmuş şeyler): genellikle kesin bir an, yani UTC zaman damgası saklayın. Kullanıcının o zamanki zaman dilimini (örneğin America/New_York) de saklayarak ekranın nasıl göründüğünü daha sonra yeniden inşa edebilirsiniz; kullanıcı profilini değiştirse bile geçmiş kayıtları yeniden yazmayın.
Planlama için (yerel duvar saatiyle gerçekleşmesi gerekenler): niyet edilen yerel tarih ve saat ile zaman dilimi kimliğini saklayın. Bunu UTC'ye çevirmeyip orijinali atmayın. “10 Mart, 09:00 Europe/Berlin” niyettir. UTC, kurallar değiştiğinde türetilmiş bir değer olabilir.
Değişiklikler normaldir: insanlar seyahat eder, ofisler taşınır, şirket politikaları değişir. Geçmiş kayıtları kullanıcı profilindeki zaman dilimi güncellemesiyle yeniden yazmayın. Gelecekteki planlar için, programın kullanıcıyı mı takip edeceğine (seyahat dostu) yoksa sabit bir konumu mu takip edeceğine (ofis dostu) karar verin ve o konumun zaman dilimini saklayın.
Sadece yerel zaman damgalarına sahip miras veriler zordur. Kaynak zaman dilimini biliyorsanız, onu iliştirin ve eski zamanı yerel olarak ele alın. Bilmiyorsanız, onu “yüzen” (floating) olarak işaretleyin ve raporlarda dürüst olun (örneğin saklanan değeri dönüştürmeden gösterin). Bu tip verileri ayrı alanlar olarak modellemek, ekranların bunları karıştırmasını önler.
DST hatalarını durdurmak için veritabanı için tek, belirsiz olmayan bir kayıt sistemi seçin ve yalnızca gösterirken dönüştürün.
Ekibiniz için kuralı yazılı hale getirin: veritabanındaki tüm zaman damgaları UTC'dir. Bunu belgelere ve tarih işlemenin yakınındaki kod yorumlarına ekleyin. Bu karar yanlışlıkla geri alınabilecek türdendir.
Pratik bir saklama deseni:
created_at_utc gibi).occurred_at_utc) ve yerel bağlam gerekliyse tz_id (IANA kimliği) gibi.tz_id toplayın, sonra sınırda (API veya form gönderimi) bir kez UTC'ye çevirin. Katmanlar arasında tekrar tekrar dönüştürmeyin.tz_id ve hesaplanan UTC). Bu, zaman tartışmalarında denetim izi sağlar.Örnek: bir kullanıcı America/Los_Angeles’ta “5 Kasım 09:00” planlarsa, occurred_at_utc = 2026-11-05T17:00:00Z ve tz_id = America/Los_Angeles kaydedin. DST kuralları sonra değişse bile neyi kastettiklerini ve ne saklandığını açıklayabilirsiniz.
PostgreSQL’de modelliyorsanız (görsel veri modelleme araçları dahil), sütun türlerini açık ve tutarlı yapın ve uygulamanın her zaman UTC yazmasını zorunlu kılın.
Çoğu DST hatası veritabanında değil, kullanıcı arayüzünde ortaya çıkar. İnsanlar gösterdiğiniz metni okur, mesajlara kopyalar ve ona göre plan yapar. Ekran belirsizse kullanıcı yanlış varsayar.
Zaman önemliyse (rezervasyonlar, biletler, randevular, teslimat pencereleri), fiş gibi gösterin: eksiksiz, belli ve etiketli.
Gösterimi tahmin edilebilir tutun:
DST kenar durumları için açık davranış belirleyin. Kullanıcılara herhangi bir zaman girmelerine izin verirseniz, eninde sonunda hiç oluşmayan veya iki kez oluşan bir zaman kabul edersiniz.
Örnek: Berlin’de bir destek görevlisi New York’ta bir müşteriyle “3 Kasım 01:30” için çağrı ayarlarsa, sonbahar tekrarında New York’ta o saat iki kez olur. UI “3 Kasım 01:30 (UTC-4)” gösterirse kafa karışıklığı gider.
Raporlar, aynı verinin görüntüleyene göre farklı toplamlar verdiğinde güveni bozar. DST hatalarını önlemek için bir raporun aslında neyi gruplayacağını seçin ve ona bağlı kalın.
İlk olarak her rapor için “gün”ün ne anlama geldiğini seçin. Destek takımı genellikle müşterinin yerel günüyle düşünür. Finans genellikle hesabın yasal zaman dilimini ister. Bazı teknik raporlar UTC günlerinde daha güvenlidir.
Yerel güne göre gruplayınca DST etrafında toplamlar değişir. Bahar ileri gününde bir yerel saat atlanır. Sonbahar geri gününde bir saat tekrar eder. Eğer “yerel tarih”e göre gruplayıp açık bir kural belirtmezseniz yoğun bir saat kaybolmuş, iki kat veya yanlış güne taşınmış görünebilir.
Pratik bir kural: her raporun bir raporlama zaman dilimi olsun ve bu başlıkta görünür olsun (örnek: “Tüm tarihler America/New_York olarak gösterilmiştir”). Bu matematiği öngörülebilir kılar ve destek için açık bir referans verir.
Çok bölgeli ekipler için kullanıcıların rapor zaman dilimini değiştirmesine izin vermek uygundur; ancak bu farklı bir bakış olarak değerlendirilmelidir. İki izleyici DST geçişleri ve gece yarısına yakın zamanlarda farklı günlük kutular görebilir. Bu normaldir, rapor seçili bölgeyi açıkça belirttiği sürece.
Birkaç seçim çoğu sürprizi önler:
Süreler özel dikkat ister. Sonbahar geri döneminde geçen 2 saatlik bir vardiya duvar-saati olarak 3 saat görünse bile, çalışan gerçekten 2 saat çalıştıysa geçen süre hâlâ 2 saattir. Kullanıcıların hangi anlamı beklediğine karar verin ve tutarlı yuvarlama uygulayın (örneğin satır başına yuvarlamak yerine toplam aldıktan sonra yuvarlayın).
DST hataları “zor matematik” değildir. Zaman içinde sızan küçük varsayımlardan kaynaklanır.
Klasik bir hata, yerel bir zaman damgası kaydedip ona UTC etiketi yapıştırmaktır. Her şey düzgün görünür ta ki başka bir saat dilimindeki biri kaydı açana kadar ve değer sessizce kayar. Daha güvenli kural basittir: bir anı (UTC) saklayın ve yerel yoruma ihtiyaç varsa doğru bağlamı (kullanıcı veya lokasyon zaman dilimi) yanında tutun.
Bir diğer sık hata sabit ofsetleri kullanmaktır (örneğin -05:00). Ofsetler DST değişiklikleri veya tarihsel kurallar hakkında bilgi içermez. America/New_York gibi gerçek IANA zaman dilimi kimlikleri kullanın.
Bazı alışkanlıklar birçok “çift vardiya” sürprizini önler:
Gizli dönüşümlere dikkat edin. Yaygın bir örnek: kullanıcının yerel zamanını UTC'ye çevirip kaydedersiniz, sonra bir UI kütüphanesi değeri yerel sanıp tekrar dönüştürür. Sonuç bir saatlik kayma olur ve bu sadece bazı kullanıcılar ve bazı tarihlerde görünür.
Son olarak, faturalama veya uyum için istemci cihaz zaman dilimini kullanmayın. Seyahat eden bir telefon seyahat sırasında bölge değiştirebilir. Bunun yerine bu tür raporları açık bir iş kuralına dayandırın, örneğin müşterinin hesap zaman dilimi veya bir site lokasyonu.
Çoğu zaman hatası yılda sadece birkaç günde ortaya çıkar, bu yüzden QA'dan kaçırılır. Çözüm doğru anları test etmek ve bu testleri tekrarlanabilir kılmaktır.
Bir DST uygulayan zaman dilimi seçin (örneğin America/New_York veya Europe/Berlin) ve iki geçiş günü için test yazın. Ardından DST kullanmayan bir bölge seçin (Asia/Singapore veya Africa/Nairobi) ve farkı görün.
Bir destek ekibi sonbahar tekrar gecesinde “01:30” takip planlarsa, UI sadece gösterilen yerel zamanı saklıyorsa hangi “01:30” kastedildiğini bilemezsiniz. İyi bir test, yerel olarak 01:30'a karşılık gelen her iki UTC zaman damgasını oluşturur ve uygulamanın bunları ayırt ettiğini doğrular.
Bu testler hızla sisteminizin doğru gerçekleri (UTC anı, zaman dilimi kimliği ve bazen orijinal yerel zaman) saklayıp saklamadığını ve saatler değiştiğinde raporların dürüst kalıp kalmadığını gösterir.
Yaz saati hataları uygulama çoğu gün doğru göründüğü için sızar. Zaman gösteren, tarihe göre filtreleyen veya rapor dışa aktaran her şeyi yayımlamadan önce bu kontrol listesini kullanın.
created_at, paid_at, message_sent_at). Yerel bağlam gerektiğinde IANA zaman dilimi kimliğini saklayın.Gerçekçi kontrol: New York'ta bir destek yöneticisi “Pazar günü oluşturulan biletler”i dışa aktarıyorsa ve Londra'daki bir ekip arkadaşı dosyayı açıyorsa, her ikisi de zaman damgalarının hangi zaman dilimini temsil ettiğini tahmin etmeden söyleyebilmelidir.
Bir müşteri New York'ta yaz saati uygulamasına geçmişken bilet açar, ama destek ekibiniz Londra'dadır.
12 Mart'ta müşteri yerel saatle 09:30'da bileti oluşturur. Bu an 13:30 UTC'dir, çünkü New York o hafta artık UTC-4'tür. Bir Londra temsilcisi 14:10 Londra saatinde yanıt verir; o hafta Londra hâlâ UTC+0 olduğundan bu 14:10 UTC olur. Yanıt, bilet oluşturulmasından 40 dakika sonra gelmiştir.
Sadece yerel zamanı ve zaman dilimi kimliğini saklamazsanız nasıl bozulur:
Daha güvenli model UI ve raporlamayı tutarlı tutar. Olay zamanını UTC zaman damgası olarak saklayın ve ilgili IANA zaman dilimi kimliğini (müşteri için America/New_York, temsilci için Europe/London) saklayın. UI'da aynı UTC anını, saklanan tarihe uygulanan kuralları kullanarak izleyicinin zaman dilimine göre gösterin.
Haftalık rapor için net bir kural seçin: “müşteri yerel gününe göre grupla.” Gün sınırlarını America/New_York'ta hesaplayın (geceden geceye), sonra bu sınırları UTC'ye çevirip o aralıkta yer alan biletleri sayın. Sayılar DST hafta boyunca bile stabil kalır.
Ürününüz DST hatalarından etkilendiyse, en hızlı çıkış yolu birkaç kural yazıp hepsine uygulamaktır. “Büyük ölçüde tutarlı” olmak zaman problemlerinin yeridir.
Kuralları kısa ve net tutun:
Düşük riskli bir şekilde uygulamaya geçirin. Önce yeni kayıtları düzeltin ki sorun büyümesin. Ardından geçmiş veriyi partiler halinde taşıyın. Taşıma sırasında hem orijinal değeri (varsa) hem de normalleştirilmiş değeri yeterince uzun tutun ki raporlardaki farkları görebilesiniz.
AppMaster (appmaster.io) kullanıyorsanız, pratik faydalardan biri bu kuralları veri modelinizde ve paylaşılan iş mantığında merkezi hale getirmektir: UTC zaman damgalarını tutarlı saklayın, yerel anlam gereken kayıtlarla birlikte IANA zaman dilimi kimliklerini tutun ve dönüştürmeleri girdi ve gösterim sınırlarında uygulayın.
Bir sonraki pratik adım, zaman dilimine güvenli tek bir rapor oluşturmak (örneğin “günde çözülen biletler”) ve bu raporu yukarıdaki test vakalarıyla doğrulamaktır. Eğer bir DST geçiş haftasında iki farklı zaman diliminde doğru kalırsa, iyi durumdasınız demektir.
Why do DST bugs happen even when the code looks correct?Yaz saati uygulaması (DST) yerel saat farkını değiştirir, gerçek olay anını değil. Yerel saat okumasını gerçek bir an gibi ele alırsanız, baharda “kaybolan” saatler ve sonbaharda “çift” saatler görürsünüz.
What’s the safest way to store timestamps in a database?Gerçek olayları UTC'de, yani mutlak bir an olarak saklayın; böylece ofsetler değişse bile değer yerinden oynamaz. Görüntülerken yalnızca görüntüleyenin yerel zamanına dönüştürün ve dönüşümler için gerçek bir zaman dilimi kimliği kullanın.
Why can’t I store just a UTC offset instead of a time zone name?Bir -05:00 gibi ofset sadece o an için UTC farkını söyler; DST kurallarını veya geçmişi içermez. America/New_York gibi bir IANA zaman dilimi adı, tarih bazlı doğru dönüşümler yapabilmek için gerekli kuralları taşır.
When should I store a value as a date instead of a timestamp?Gerçek an olmayan değerleri (doğum günü, fatura vadesi, “her ayın 5’inde yenilenir” gibi) tarih alanı olarak saklayın. Bunları zaman damgası olarak saklamak, saat dilimi dönüşümleri yüzünden bir günü önceye veya sonrasına taşıyabilir.
How should my app handle times that are skipped or repeated during DST switches?Baharda bazı yerel saatler hiç oluşmayabilir — uygulama geçersiz seçimleri engellemeli ve kullanıcıya bir sonraki geçerli zamanı önermeli. Sonbaharda ise aynı yerel saat iki kez oluşur; UI kullanıcının hangi örneği kastettiğini seçmesine izin vermeli (örneğin, ofset göstererek).
Should I convert scheduled meetings to UTC when saving them?Planlama verilerinde kullanıcının niyeti önemlidir: niyet edilen yerel tarih/saat ile tz_id (zaman dilimi kimliği) saklayın. Çalıştırma için türetilmiş bir UTC anı saklayabilirsiniz ama orijinal yerel niyeti atmayın; kurallar değiştiğinde anlam kaybolur.
How do I stop reports from showing different daily totals for different users?Her rapor için bir raporlama zaman dilimi seçin ve başlıkta görünür yapın, böylece “gün”ün ne anlama geldiği bellidir. Yerel güne göre gruplayınca DST yakınlarında günler 23 veya 25 saat olabilir; bunu açıkça belirttiğiniz sürece tutarlılığı korursunuz.
What’s the most common mistake that causes the “one-hour shift” bug?Çoğu “bir saatlik kayma” hatası, bir katmanın zaman damgasını yerel sanıp diğerinin UTC sanmasıyla oluşur. Girdi bir kere ayrıştırılmalı, bir kere saklanmalı ve gösterim için bir kere formatlanmalıdır; çift dönüşümden kaçının.
How should I calculate durations across DST changes?Süreleri mutlak birim (örneğin saniye) olarak saklayın ve sonra topladıktan sonra gösterime çevirin. Ücret bordrosu, SLA veya vardiya süresi gibi durumlarda kullanıcıların hangi anlamı beklediğini belirleyin: duvar-saati mi yoksa geçen süre mi? Sonra tutarlı yuvarlama uygulayın.
What tests catch most DST bugs before customers do?En az bir DST uygulayan zaman diliminde iki geçiş günü için testler yazın ve bir DST uygulamayan bölgeyle (örneğin Asia/Singapore veya Africa/Nairobi) karşılaştırın. Kaybolan saat, tekrar eden saat, gece yarısı geçişleri ve rapor gruplama testleri genelde en çok hatayı yakalar.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
