Yazılımda Saat Dilimi Sorunu: Tarihler Neden Bir Gün Kayar?

Aynı kayıt bir ekranda 23:40, başka bir ekranda ertesi günün 02:40'ı olarak görünüyorsa veri bozuk değildir; saatin nasıl saklandığı ile nasıl gösterildiği karışmıştır. Kalıcı çözüm zaman damgalarını tek bir referans diliminde saklamak ve kullanıcının dilimine yalnızca gösterim anında çevirmektir. Aşağıda tarihlerin neden bir gün kaydığını, hangi alanın tarih hangisinin zaman damgası olması gerektiğini ve gün sonu raporlarının sınırının nasıl kurulduğunu bulacaksınız.

Sorun saklamada mı, gösterimde mi?

Bir zaman değeri üç farklı anlamda tutulabilir: bir an (işlem tam olarak ne zaman oldu), bir takvim günü (fatura hangi güne ait) ve bir saat dilimli yerel saat (randevu hangi şehirde saat kaçta). Bu üçü aynı alanda tutulmaya kalkıldığında kayma başlar.

Yaygın hata, sunucunun yerel saatini doğrudan yazmaktır. Sunucu taşındığında, bulut sağlayıcının dilimi farklı olduğunda ya da ekip başka bir ülkeden bağlandığında aynı tablodaki kayıtlar artık aynı ölçekte değildir. Daha sinsi hâli, kaydın bir yerde yerel saatle bir yerde referans dilimiyle yazılmasıdır: veri tek tabloda, ama iki dilde tutulur ve hangi satırın hangi dilde olduğunu söyleyen bir alan yoktur.

Doğru yaklaşım nettir. Bir an için zaman damgası alanı kullanılır, tek bir referans diliminde saklanır ve arayüz her gösterimde kullanıcının dilimine çevirir. Çeviriyi veri tabanına değil, sunuma bırakmak ilkesi bu konudaki tek kuraldır.

Tarih mi, zaman damgası mı?

Her zaman alanına saat eklemek zararsız görünür ama rapor sınırlarını bozar. Salt takvim günü olan alanlara saat yazıldığında dilim çevirisi o kaydı bir gün öteye taşıyabilir.

Bu ayrımı sonradan yapmak zordur, çünkü mevcut veride hangi kaydın hangi varsayımla yazıldığı bilinmez. Yeni projede baştan, mevcut projede ise taşıma sırasında karar verilir.

Gün sonu ve ay sonu raporları neden tutmaz?

Gün bazlı raporların klasik hatası aralığın iki ucunu da kapalı kurmaktır. Başlangıç ile bitiş arasındaki aralık, bitiş gününün saat 00:00'ını da içeriyorsa ertesi günün ilk kayıtları bugünün raporuna girer; bitişi gece yarısından bir saniye önce bitirmek ise saniyenin kesirlerinde kalan kayıtları dışarıda bırakır.

Güvenli kalıp yarı açık aralıktır: başlangıç dahil, bitiş hariç. Yani rapor, seçilen günün başından ertesi günün başına kadar sorgulanır. Bu kalıp hem gün hem ay hem de vardiya raporlarında aynı şekilde çalışır ve sınır kayıtlarının iki rapora birlikte girmesini engeller.

İkinci karar, günün kimin saatine göre başladığıdır. Tek ülkede çalışan bir işletmede bu soru görünmez; birden çok ülkede ya da gece yarısını aşan vardiyalarda raporun hangi dilime göre gruplandığı açıkça yazılır. Aynı veriden iki farklı doğru toplam çıkabilir ve hangisinin kullanıldığı rapor başlığında görünmelidir.

Yaz saati uygulaması ve kayıp saat

Saat ileri alınan ülkelerde yılda bir kez var olmayan bir saat, bir kez de iki defa yaşanan bir saat oluşur. Yerel saatle saklayan sistemlerde bu iki an tanımsızdır: var olmayan saate randevu verilebilir, tekrarlanan saatte iki kayıt aynı yerel değere sahip olur ve sıralama bozulur.

Referans diliminde saklayan bir sistemde bu sorun yaşanmaz, çünkü zaman çizgisinde boşluk ya da tekrar yoktur. Yine de iki noktaya dikkat edilir: gece çalışan işlerin yerel saate göre planlanması atlanan ya da iki kez çalışan iş üretebilir, uzun vadeli randevular ise kullanıcının beklediği yerel saati koruyacak şekilde saklanmalıdır.

Entegrasyonlarda tarih biçimi

Sistemler arasında tarih taşırken en sık görülen hata biçimi yazıyla anlaşmaya bırakmaktır. Gün ve ayın sırası tahminle çözülmez; 03/04 iki sistemde iki farklı güne karşılık gelir.

• Zaman damgaları diliminin açıkça yazıldığı standart bir biçimde taşınır; dilim bilgisi olmayan bir değer yarım veridir.
• Karşı sistem yerel saat gönderiyorsa hangi dilimde olduğu yazılı olarak teyit edilir ve girişte referans dilimine çevrilir.
• Salt tarih alanları saat eklenmeden taşınır; saat eklendiği anda çeviri kaymayı geri getirir.
• Gelen değerlere sınır testi yapılır: gelecekteki uçuk tarihler ve çok eski tarihler reddedilir ya da işaretlenir.
• Kayıt günlüklerinde hem gelen ham değer hem çevrilmiş değer tutulur; sonradan tartışma ancak bu ikisiyle çözülür.

Kısa kontrol listesi

• Zaman damgaları tek bir referans diliminde mi saklanıyor, çeviri yalnızca gösterimde mi yapılıyor?
• Salt takvim günü olan alanlara saat yazılmış mı?
• Rapor aralıkları başlangıç dahil, bitiş hariç kurulmuş mu?
• Raporun hangi dilime göre gruplandığı ekranda yazıyor mu?
• Gece çalışan işler yaz saati geçişlerinde atlanıyor ya da iki kez çalışıyor mu?
• Entegrasyonlarda dilim bilgisi olmayan tarih kabul ediliyor mu?

KAV Yazılım, entegrasyon ve raporlama projelerinde zaman alanlarını bu ayrımla kurar; mevcut sistemlerde ise kaymanın hangi katmanda oluştuğunu tespit edip veri modelini sadeleştirir.