İş Yazılımlarında Saat Dilimi: Baştan Konulacak 7 Kural

İstanbul'da, online bir portal üzerinden Almanya'daki ve Körfez'deki müşterilere satış yapmaya başlamış bir yedek parça toptancısı düşünün. Berlin'deki bir müşteri ayın son günü saat 23.30'da sipariş veriyor. İstanbul'da saat çoktan ertesi günün 01.30'u. Ay sonu satış raporu siparişi yeni aya yazıyor. Müşterinin faturasında bir tarih, depo ekranında başka bir tarih görünüyor; satış müdürü de temsilcinin aylık hedefi neden tek bir siparişle kaçırdığını merak ediyor.

Hiçbir şey çökmedi. Hiçbir kayıtta hata görünmedi. Sistem kendisine söyleneni tam olarak yaptı; ona günün hangi gün olduğunu kimse söylememişti.

Saat dilimi sorunları böyle davranır. Yazılımı nadiren durdurdukları için testte de nadiren yakalanırlar. Ekranlar, raporlar ve insanlar arasında küçük anlaşmazlıklar olarak ortaya çıkarlar ve işletme bir sınırı geçtiğinde ya da ekip birden fazla şehirden çalışmaya başladığında pahalı hâle gelirler. Aşağıdaki kurallar projenin başında ucuza konuşulur, sonradan eklenmeye çalışıldığında ise zahmetlidir.

1. Anları UTC olarak saklayın ve bunu yazın

Bir şey belirli bir anda olduğunda, örneğin bir sipariş verildiğinde, bir ödeme geçtiğinde ya da bir kullanıcı giriş yaptığında, o anı veritabanında UTC (Eşgüdümlü Evrensel Zaman) olarak saklayın. Yerel saate yalnızca birine gösterirken çevirin.

Nedeni basit: UTC yaz saati uygulamasıyla hiç kaymaz ve her sunucuda aynı anlama gelir. Sistemin bir parçası İstanbul saatini, başka bir parçası da başka bir ülkedeki veri merkezinde olabilecek sunucunun saatini yazıyorsa, ikisini sonradan karşılaştırmanın yolu yoktur.

Bu kuralı proje belgelerine yazın. Bir yıl sonra ekibe katılan bir geliştirici, bir zaman damgası sütununun ne taşıdığını tahmin etmek zorunda kalmamalı.

2. Her tarih bir an değildir

Bazı tarihler an değildir ve asla çevrilmemelidir. Doğum günü, sözleşme bitiş tarihi, resmî tatil ya da faturanın üzerinde yazan tarih takvim tarihleridir. 14 Mart'taki bir doğum günü her ülkede 14 Mart'tır.

Bunlar zaman damgası olarak saklanıp gösterilirken çevrilirse, New York'taki bir müşteri doğum gününü 13 Mart olarak görebilir. Takvim tarihlerini saatsiz ve saat dilimsiz, düz tarih olarak tutun. Bir ekranı yapmadan önce her tarih alanı için sorun: bu bir an mı, yoksa takvimde bir gün mü?

3. Günün kime ait olduğuna karar verin

Bir rapordaki "gün"ün bir sahibi olmalı. Satış günü şirketin merkezinin bulunduğu İstanbul'daki gün mü, yoksa müşterinin bulunduğu yerdeki gün mü? İki cevap da makul; cevapsız kalmak değil.

Çoğu şirket için cevap, iç raporlarda merkezin saat dilimi, sipariş onayı gibi müşterinin gördüğü her şeyde ise müşterinin kendi saat dilimidir. Seçimi her rapor için yazın. Toptancı örneğinde aylık raporların İstanbul saatine göre tutulmasına karar vermek sorun değildir; yeter ki satış ekibi bunu bilsin ve hedefler de aynı şekilde konsun.

4. Kesim saatleri bir yere aittir

"14.00'ten önce verilen siparişler bugün kargoda" belirli bir şehirde verilmiş bir sözdür. Depo bir yerdedir ve kesim saati o yere aittir; ne müşteriye ne de sunucuya.

Bu tür kuralları saat dilimleriyle birlikte saklayın ve önemli olduğu yerde müşteriye kesim saatini kendi saatiyle gösterin: iki saat uzaktaki biri için "Aynı gün gönderim için 2 saat 10 dakika içinde sipariş verin" ifadesi "14.00'ten önce"den daha açıktır.

Aynısı destek saatleri, teslimat aralıkları ve randevu saatleri için de geçerlidir. Bir klinikteki randevu, hasta hangi saat diliminden almış olursa olsun, kliniğin saat diliminde gerçekleşir.

5. Gece işlerinizin gerçekte ne zaman çalıştığını kontrol edin

Birçok sistem zamanlanmış işleri "gece yarısı" çalıştırır: günü kapatmak, bir özet e-postası göndermek, stoku başka bir sistemle eşitlemek. Sunucular çoğu zaman UTC ile çalışır; bu yüzden UTC'deki bir sunucuda gece yarısına kurulan iş İstanbul'da 03.00'te, Berlin'de ise kışın 01.00'de, yazın 02.00'de çalışır.

Bazen bu zararsızdır. Bazen gün sonu işi geç gelen bir sipariş ulaşmadan günü kapatır ya da stok eşitlemesi başka bir bölgedeki müşteriler için yoğun bir akşamın ortasında çalışır. Zamanlanmış işlerinizi listeleyin, her birinin yanına çalışması gereken yerel saati yazın ve sunucu ayarlarının buna uyduğunu kontrol edin.

6. Yaz saati uygulaması başka yerlerde hâlâ var

Türkiye 2016'dan bu yana sabit bir saat farkıyla yaşıyor; bu da İstanbul'daki bir ekibin Avrupa'nın ve Kuzey Amerika'nın büyük kısmının yılda iki kez saat değiştirdiğini unutmasını kolaylaştırıyor. Londra'daki bir müşteri İstanbul'un kışın üç, yazın iki saat gerisindedir ve bu değişim Avrupa'da ve ABD'de farklı tarihlerde olur.

Bu yüzden "Almanya UTC+1'dir" gibi sabit farklar asla koda yazılmamalıdır. Saat dilimlerini adıyla saklayın, örneğin "Europe/Berlin", ve her tarih için farkı güncel tutulan bir saat dilimi kütüphanesinin hesaplamasına bırakın. Her yıl iki değişim gününde zamana duyarlı her şeyi hızlıca kontrol edin: zamanlanmış işler, hatırlatmalar ve randevu aralıkları.

7. Açık değilse saat dilimini gösterin

Bir ekran saat gösteriyorsa ve okuyan kişinin başka bir şehirde olması makulse, saat diliminin yanına yazın: "Teslimat aralığı 10.00–12.00 (İstanbul saati)". Birkaç karakter tutar ve aksi hâlde bir telefona dönüşecek bir yanlış anlamayı önler.

İç kullanıcılar için saat dilimini tarayıcıdan tahmin etmek yerine herkesin profilinde kendi saat dilimini seçmesine izin verin. Bir hafta yolculuğa çıkan bir müdür bütün raporların iki saat kaydığını görmemeli.

Kısa bir deneme

Bilgisayarınızın saat dilimini Los Angeles gibi uzak bir yere alın ve sisteminizin ana akışlarından geçin: akşam geç saatte sipariş verin, bugünün raporunu açın, bir randevu alın, bir faturanın tarihine bakın. Değişmemesi gereken yerde değişen ve değişmesi gereken yerde aynı kalan her tarih, bu listeden eksik olan bir kurala işaret eder.

Kısaca

• Anları UTC olarak saklayın ve kuralı yazın.
• Doğum günü ve fatura tarihi gibi takvim tarihlerini düz tarih olarak tutun.
• Rapor rapor, "gün"ün kime ait olduğuna karar verin.
• Kesim saatlerini ve randevuları ait oldukları yere bağlayın.
• Zamanlanmış işleri, her birinin çalışması gereken yerel saatle listeleyin.
• Saat dilimlerini sabit farkla değil, adıyla saklayın.
• Okuyan kişi başka bir yerde olabilecekse saat dilimini gösterin.

Bunların hiçbiri özel bir ürün gerektirmez. İlk tablo oluşturulmadan önce, hâlâ bir veri taşımasına değil bir konuşmaya mal olurken verilmesi gereken birkaç karar gerektirir.

Sınır ötesine satış yapan şirketler için web yazılımı geliştirirken, bu tarih ve saat kuralları veritabanı tasarlanmadan önce müşteriyle netleştirdiğimiz sorular arasındadır.