Az önce oluşturduğunuz sipariş "3 saat önce" görünüyor. Blog yazınız yarın yayınlanmış gibi duruyor. Zamanlanmış göreviniz beklediğiniz saatten farklı bir zamanda çalışıyor.
Bu sorunların hepsi zaman dilimi uyumsuzluğundan kaynaklanır. Bu yazı, hosting ortamında zaman katmanlarını ve doğru yapılandırmayı anlatıyor.
Dört Katman
Bir tarihin ekranda doğru görünmesi, dört ayrı ayarın uyumuna bağlıdır:
| Katman | Neyi etkiler |
|---|---|
| Sunucu sistem saati | Zamanlanmış görevler, log kayıtları |
| Uygulama zaman dilimi | Kod içinde üretilen tarihler |
| Veritabanı zaman dilimi | Veritabanı fonksiyonlarıyla üretilen tarihler |
| Görüntüleme zaman dilimi | Kullanıcıya gösterilen saat |
Sorun genellikle ikinci ve üçüncü katmanın farklı olmasından doğar: uygulamanız bir zaman dilimini, veritabanınız başka bir zaman dilimini kullanıyordur. Aynı tablodaki iki tarih alanı, hangisinin nasıl üretildiğine bağlı olarak farklı saatler gösterir.
Belirtiden Teşhis
- Tüm tarihler sabit bir fark gösteriyor. Tek bir zaman dilimi ayarı yanlış. Düzeltmesi kolaydır.
- Bazı tarihler doğru, bazıları yanlış. Uygulama ve veritabanı farklı ayarlarda. En sık karşılaşılan durum budur.
- Zamanlanmış görevler yanlış saatte çalışıyor. Sunucu sistem saati farklı bir zaman diliminde.
- Yılın belirli dönemlerinde bir saat kayıyor. Yaz saati uygulaması kaynaklı — sabit bir saat farkı kullanılıyor demektir.
Son madde önemli bir tasarım hatasına işaret eder: zaman dilimini sabit bir saat farkı olarak tanımlamak yerine, bölge adı kullanmak gerekir. Bölge adı, yaz saati değişikliklerini kendiliğinden hesaba katar.
Doğru Yaklaşım: UTC Sakla, Yerelde Göster
Uzun vadede sorun çıkarmayan tek yöntem şudur:
- Tüm tarihleri UTC olarak saklayın. Veritabanında evrensel zaman kullanın.
- Görüntülerken kullanıcının zaman dilimine çevirin. Sunum katmanında.
- Sunucu ve uygulamayı UTC'ye ayarlayın. Tutarlılık için.
- Kullanıcı zaman dilimini kaydedin. Çok bölgeli hizmet veriyorsanız.
Bu yaklaşımın avantajları:
- Yaz saati değişiklikleri veri katmanını hiç etkilemez
- Farklı bölgelerdeki kullanıcılar kendi saatlerini görür
- Sunucu taşındığında veriler bozulmaz
- Tarih karşılaştırmaları her zaman doğru sonuç verir
Tek dezavantajı, veritabanına doğrudan baktığınızda saatleri zihninizde çevirmeniz gerekmesidir. Bu, kazanılan kararlılık yanında küçük bir bedeldir.
Ayarları Nerede Yaparsınız?
Uygulama Tarafı
Uygulamanızın yapılandırmasında zaman dilimi tanımlanmalıdır. Bunu varsayılana bırakmak, sunucu değiştiğinde tarihlerin kaymasına yol açar.
Ayarı bölge adıyla yapın; sabit saat farkı yazmayın.
Veritabanı Bağlantısı
Veritabanı sunucusunun zaman dilimini değiştiremeyebilirsiniz — paylaşımlı ortamlarda bu genellikle sabittir. Ancak bağlantı başına zaman dilimi tanımlayabilirsiniz.
Uygulamanız veritabanına bağlandığında ilk iş olarak zaman dilimini ayarlarsa, o oturumdaki tüm tarih işlemleri doğru çalışır.
Zamanlanmış Görevler
Görev planlayıcısı sunucunun sistem saatini kullanır. Sunucu farklı bir zaman dilimindeyse, tanımladığınız saat beklediğiniz saat olmaz.
Çözüm: sunucunun hangi zaman diliminde olduğunu öğrenin ve görev saatlerini buna göre hesaplayın. Ya da görevi sık çalıştırıp, çalışma zamanı kontrolünü kod içinde yapın.
Sık Yapılan Hatalar
- Sabit saat farkı kullanmak. Yaz saati uygulamasında kayar. Bölge adı kullanın.
- Tarihi metin olarak saklamak. Karşılaştırma ve sıralama bozulur; uygun tarih veri tipi kullanın.
- Kullanıcının saatine güvenmek. Tarayıcıdan gelen zaman bilgisi güvenilir değildir; kritik kayıtlarda sunucu saati esas alınmalı.
- Zaman dilimini yalnızca bir yerde ayarlamak. Tüm katmanlar tutarlı olmalı.
- Test etmeden bırakmak. Ayarı yaptıktan sonra bir kayıt oluşturup kontrol edin.
Üçüncü madde bir güvenlik konusudur: kullanıcının cihaz saati değiştirilebilir. Sipariş zamanı, ödeme kaydı veya süre kontrolü gibi kritik alanlarda mutlaka sunucu saatini kullanın.
Taşımadan Sonra
Site taşıdıktan sonra tarihlerin kayması yaygın bir durumdur. Yeni sunucunun varsayılan zaman dilimi farklıdır.
Taşıma sonrası kontrol listesi:
- Yeni sunucunun sistem zaman dilimini öğrenin
- Uygulama yapılandırmanızdaki zaman dilimi ayarının hâlâ tanımlı olduğunu doğrulayın
- Veritabanı bağlantısında zaman dilimi ayarlandığını kontrol edin
- Zamanlanmış görev saatlerini yeniden hesaplayın
- Bir test kaydı oluşturup tarihini kontrol edin
Dördüncü madde sıkça atlanır ve sessiz sorunlar üretir: gece yarısı çalışması gereken bir görev, yeni sunucuda öğleden sonra çalışıyor olabilir ve bunu kimse fark etmez.
Çok Bölgeli Hizmet
Farklı ülkelerdeki kullanıcılara hizmet veriyorsanız:
- Kullanıcı profilinde zaman dilimi tutun. Kayıt sırasında sorun veya tarayıcıdan tespit edip onaylatın.
- Göreli zaman gösterimi kullanın. "2 saat önce" ifadesi zaman diliminden bağımsızdır.
- Kritik tarihlerde zaman dilimini belirtin. Randevu ve son teslim tarihlerinde hangi saate göre olduğunu yazın.
Üçüncü madde iş açısından önemlidir: bir kampanyanın bitiş saati, hangi zaman diliminde olduğu yazılmadığında müşteri şikâyeti üretir.
Bu ayarların bir kısmı sunucu düzeyinde tanımlanır. Hosting paketinizde PHP ayarlarını panelden değiştirebiliyorsanız zaman dilimini oradan; değiştiremiyorsanız uygulama yapılandırmanızdan tanımlayın.
Sonuç
Tarih sorunlarında belirti size katmanı söyler: tüm tarihler sabit fark gösteriyorsa tek bir ayar yanlıştır, bazıları doğru bazıları yanlışsa uygulama ve veritabanı farklı zaman dilimlerindedir. Kalıcı çözüm tek bir ilkedir: tarihleri UTC olarak saklayın, kullanıcıya gösterirken çevirin. Zaman dilimini tanımlarken sabit saat farkı değil bölge adı kullanın — yaz saati değişikliklerini yalnızca o doğru hesaplar. Ve taşıma sonrası zamanlanmış görev saatlerini yeniden hesaplamayı unutmayın.
Sıkça Sorulan Sorular (SSS)
Tarihler neden yanlış görünüyor?
Zaman dilimi katmanlarından biri diğerlerinden farklı. Tüm tarihler sabit bir fark gösteriyorsa tek bir ayar yanlıştır; bazıları doğru bazıları yanlışsa uygulamanız ve veritabanınız farklı zaman dilimleri kullanıyordur.
Tarihleri UTC olarak mı saklamalıyım?
Evet, uzun vadede sorun çıkarmayan tek yöntem budur. Yaz saati değişiklikleri veri katmanını etkilemez, farklı bölgelerdeki kullanıcılar kendi saatlerini görür ve sunucu taşındığında veriler bozulmaz. Görüntülerken kullanıcının zaman dilimine çevirin.
Zamanlanmış görevlerim neden farklı saatte çalışıyor?
Görev planlayıcısı sunucunun sistem saatini kullanır ve sunucu farklı bir zaman diliminde olabilir. Sunucunun hangi zaman diliminde olduğunu öğrenip görev saatlerini buna göre hesaplayın.
Yılda iki kez bir saat kayıyor, neden?
Zaman dilimini bölge adı yerine sabit bir saat farkı olarak tanımlamışsınız. Sabit fark, yaz saati uygulamasını hesaba katmaz. Bölge adı kullandığınızda bu değişiklikler kendiliğinden doğru hesaplanır.
