E-pin Satış Scriptinde Saatler Kaymış mı Görünüyor? Sunucunda Aslında Üç Ayrı Saat Çalıştığını ve Mutabakatını Nasıl Bozduğunu Anlatıyoruz

Çoğu kişi zaman dilimi sorununu tek bir ayar hatası sanır: "sunucunun saati yanlış, düzeltirim biter." Panelde tarih ayarını bulur, Türkiye'yi seçer, sayfayı yeniler. Sipariş listesindeki saatler düzelir gibi olur. Sonra ay sonu gelir, ödeme sağlayıcısının raporuyla kendi satış raporunu karşılaştırır ve iki rapor arasında üç saatlik bir kayma bulur. Bazı siparişler bir günlük raporun hem sonunda hem başında görünür. İşte o an anlaşılır ki düzelen şey sadece ekrandaki yazıydı.

Gerçek şu: bir e-pin satış scriptinde saat tek yerden gelmez, en az üç ayrı yerden gelir ve bu üçü birbirinden bağımsız olarak yanlış olabilir. Uygulamanın çalıştığı dil ortamının kendi saati vardır, veritabanı sunucusunun ayrı bir saati vardır, müşterinin tarayıcısının ise bambaşka bir saati vardır. Üstüne zamanlanmış görevlerin çalıştığı sistem saati eklenir. Bu yazıda bu katmanları tek tek açacak, hangi kaymanın nereden geldiğini nasıl ayırt edeceğini ve kalıcı çözümün neden "ayar değiştirmek" değil "mimari kural koymak" olduğunu göstereceğiz.

Saat Gerçekten Kaymış mı, Yoksa Üç Ayrı Saat mi Var?

Teşhise başlamanın en hızlı yolu aynı anı dört farklı yerden okumaktır. Sipariş oluştuğu anda hem uygulamanın ürettiği zaman damgasını, hem veritabanının kendi zaman fonksiyonunun döndürdüğü değeri, hem sunucunun sistem saatini, hem de müşteri tarayıcısından gelen yerel zamanı aynı kayda yazdır. Bu dört değeri yan yana gördüğünde kaymanın kaç saat olduğu ve hangi katmandan doğduğu bir bakışta ortaya çıkar.

Uygulama ile veritabanı arasındaki fark üç saat çıkıyorsa neredeyse kesin olarak biri yerel saat, diğeri evrensel saat kullanıyordur. Fark bir saat çıkıyorsa yaz saati kaynaklı bir eskimiş tanım vardır. Fark değişken çıkıyorsa, örneğin bazı kayıtlarda üç bazılarında iki saat, o zaman zaman damgaları farklı yollardan yazılıyor demektir: bir kısmı uygulamadan, bir kısmı veritabanının varsayılan değerinden. Bu son durum bir dijital ürün satış scriptinde en tehlikelisidir çünkü tek bir düzeltme tüm kayıtları onarmaz.

Dilin Saati, Veritabanının Saati ve Tarayıcının Saati Neden Asla Aynı Değil?

Uygulama katmanının saati, çalışma zamanı yapılandırmasından gelir. Bu ayar barındırma sağlayıcısının varsayılanıyla gelir ve çoğu paylaşımlı sunucuda evrensel saat olarak bırakılır. Veritabanı sunucusu ise kendi başına bir servistir; onun oturum bazlı bir zaman dilimi vardır ve uygulamanın ayarından hiç etkilenmez. Yani bir kayda zaman damgasını uygulama yazıyorsa yerel saat, veritabanının otomatik alanı yazıyorsa evrensel saat düşer. Aynı tabloda iki farklı gerçeklik oluşur.

Tarayıcı tarafı üçüncü ve en kaotik kaynaktır. Müşterin yurt dışındaysa, telefonunun saati elle değiştirilmişse veya bir gizlilik eklentisi saat dilimini maskeliyorsa, senin ekranda gösterdiğin "sipariş saati" onun için anlamsız olur. Bu yüzden olgun bir e-pin yazılımı tarayıcıdan gelen zamana asla karar verici olarak güvenmez; onu sadece gösterim tercihi olarak kullanır. Karar her zaman sunucunun ürettiği tek bir zaman damgasına dayanmalıdır.

Türkiye Saati Neden Bazen Üç, Bazen İki Saat İleri Görünür?

Türkiye 2016'dan sonra kalıcı olarak evrensel saatin üç saat ilerisine geçti ve yaz saati uygulamasını bıraktı. Ancak sunucularda saat dilimi tanımları bir veri tabanından okunur ve bu veri tabanı güncellenmezse sistem hâlâ eski kuralı uygular: yılın bir bölümünde iki saat, diğer bölümünde üç saat ileri sayar. Sonuç, yılda iki kez kendiliğinden ortaya çıkan ve kimsenin kod değişikliğiyle açıklayamadığı bir saatlik kaymadır.

Bu durumun en can sıkıcı yanı tutarsız oluşudur. Eski kayıtlar bir kuralla, yeni kayıtlar başka kuralla yazılmıştır. Geçmiş raporlarını yeniden ürettiğinde sayılar değişir ve hangisinin doğru olduğunu bilemezsin. Bu yüzden zaman dilimi tanımlarının güncel tutulması, bir epin yazılım kurulumunda güvenlik yamaları kadar önemlidir. Sabit ofset yazmak, yani doğrudan "üç saat ekle" demek de kısa vadede işe yarar gibi görünse de kuralların gelecekte tekrar değişmesi hâlinde aynı hatayı kalıcı hâle getirir.

Zamanlanmış Görevler Neden Yanlış Saatte Tetikleniyor?

Otomatik tedarikçi stok senkronizasyonu, günlük satış özeti, terk edilmiş sepet hatırlatması, bakiye uyarısı... Bir dijital ürün satış yazılımının en kritik parçaları zamanlanmış görevlerdir ve bunlar uygulamanın zaman dilimi ayarını görmez. Barındırma panelinin kendi saatiyle çalışırlar. Günlük raporun gece yarısında kapanmasını bekliyorsan ama panel evrensel saat kullanıyorsa, raporun aslında akşam dokuzda kapanır ve son üç saatin satışı ertesi güne yazılır.

Bu hatanın maliyeti doğrudan paradır. Ay sonu raporun eksik çıkar, bayi komisyon hesabı kayar, kampanya bitiş saatinden sonra sipariş kabul edilir. Doğru yaklaşım şudur: görevleri saat hassasiyeti gerektirmeyecek biçimde tasarla. Yani "gece yarısı çalış ve dünü raporla" demek yerine "çalıştığın anda, uygulama saatine göre kapanmış son günü raporla" mantığını kur. Görev ne zaman tetiklenirse tetiklensin doğru sonucu üretmelidir. Böylece panel saatiyle uygulama saati arasındaki fark zararsız hâle gelir.

Doğru Mimari: Evrensel Saatte Sakla, Yerelde Göster

Kalıcı çözüm tek bir kuralla özetlenir: veriyi her zaman tek bir referans dilimde, yani evrensel saatte sakla; kullanıcıya gösterirken yerel saate çevir. Bu kuralın üç pratik sonucu vardır. Birincisi, veritabanındaki hiçbir zaman damgası ülke veya yaz saati kurallarına bağlı olmaz; kurallar değişse bile veri sabit kalır. İkincisi, ödeme sağlayıcısı ve tedarikçi API'leri de genellikle evrensel saat kullandığı için mutabakat doğrudan tutar. Üçüncüsü, ileride farklı ülkelere satış yapmaya başladığında tek bir gösterim katmanını değiştirerek işi bitirirsin.

Uygulamada bu, zaman damgalarının tek bir merkezi noktadan üretilmesi anlamına gelir. Kodun hiçbir yerinde doğrudan "şimdi" çağrısı yapılmaz; her zaman merkezi bir zaman servisinden alınır. Veritabanının otomatik zaman alanları yerine uygulama tarafından yazılan açık alanlar kullanılır. Gösterim tarafında ise tek bir biçimlendirme fonksiyonu tüm ekranları besler. Pinova bu kuralı varsayılan olarak uygular: kayıt evrensel saatte tutulur, panel ve müşteri ekranı işletmenin seçtiği dilime çevirir, raporlar her iki değeri de karşılaştırılabilir biçimde sunar.

Mutabakat, Fatura ve Yasal Tarafta Saat Kayması Ne Kadara Patlar?

Saat kayması ilk bakışta kozmetik bir sorun gibi görünür, ama sonuçları ciddidir. Ödeme sağlayıcısının gün sonu raporu ile senin satış raporun eşleşmediğinde, aradaki farkın hangi işlemlerden geldiğini bulmak saatler alır. Bayi komisyonları yanlış dönemde hesaplanır. İade süresi hesabı bir gün kayar ve hak sahibi olmayan bir müşteriye iade yapılır ya da hak sahibi olan müşteriye reddedilir. Fatura tarihleri muhasebe dönemine yanlış düşer.

Bunların hepsi güven kaybına dönüşür. Bayin sana "raporun yanlış" dediğinde, sorun aslında bir zaman dilimi tanımıysa bile itibar zedelenir. Bu yüzden zaman yönetimi bir detay değil, dijital ürün satışının temel muhasebe altyapısıdır. Sistemin bu konuda nasıl davrandığını ve raporların hangi referansla üretildiğini özellikler bölümünde görebilirsin.

Zaman dilimi kayması, bir e-pin satış yazılımının en sessiz ama en pahalı arızasıdır: hiçbir hata mesajı vermez, sadece sayıları yanlış gösterir. Doğru kurulmuş bir sistemde aynı sipariş panelde, müşteri e-postasında, raporda ve mutabakat dosyasında tek bir gerçeği anlatır. Bunun nasıl göründüğünü merak ediyorsan canlı demo üzerinden sipariş kayıtlarını ve rapor ekranlarını inceleyip paket seçimine oradan geçebilirsin.