Sitemdeki Saat Yanlış Görünüyor: PHP ve MySQL Zaman Dilimi Ayarı

Saat 14:20'de sipariş veriyorsunuz, yönetim panelinde sipariş "11:20" olarak listeleniyor. Aynı sitede blog yorumları da üç saat geride görünüyor, ama tuhaf biçimde müşteriye giden e-posta bildiriminin üstündeki saat doğru. Üstelik hosting panelinden baktığınızda sunucu saati gayet normal duruyor. Bu tablo neredeyse hiçbir zaman tek bir "sunucunun saati bozuk" hikâyesi değildir; birbirinden bağımsız çalışan birkaç katmanın farklı zaman dilimlerini kullanmasıdır.

Bir PHP uygulamasında bir tarihin ekrana basılmasına kadar en az dört karar noktası vardır: işletim sisteminin saati ve zaman dilimi, PHP'nin date.timezone ayarı, veritabanı bağlantısının oturum zaman dilimi ve uygulamanın kendi ayar dosyasındaki tercih. Bunlardan biri diğerleriyle çelişince kayıt bir yerde doğru, başka bir yerde üç saat kaymış görünür. Yanlış katmanı düzeltirseniz sorun ya hiç kaybolmaz ya da bir yeri düzeltirken başka bir yeri bozarsınız.

Aşağıda önce bu dört katmanı ayırıp her birini tek başına ölçmenizi sağlayan kısa testleri paylaşıyorum, sonra her katmanın nasıl düzeltileceğini ve en önemlisi bir daha bu duruma düşmemek için verinin nasıl saklanması gerektiğini anlatıyorum. Türkiye özelinde kritik bir ayrıntıya da değineceğiz: 2016'dan beri yaz saati uygulanmadığı için Europe/Istanbul ile +03:00 bugün aynı sonucu üretiyor, ama ikisi aynı şey değil.

Saat Hatası Aslında Dört Ayrı Katmanda Olabilir#

Bir tarihin yolculuğunu şöyle düşünün. İşletim sistemi donanım saatinden bir zaman damgası tutar; bu damga her zaman UTC'dir. Sistemin zaman dilimi ayarı, bu damganın insana gösterilirken hangi yerel saate çevrileceğini belirler. PHP kendi zaman dilimini bu sistem ayarından miras almaz; date.timezone boş bırakılırsa PHP 5.4'ten bu yana sessizce UTC varsayar. Yani sunucunun date komutu 14:20 dese bile PHP date('H:i') çağrısında 11:20 döndürebilir.

MySQL ise üçüncü bir dünyadır. NOW() fonksiyonu, bağlantının oturum zaman dilimine göre değer üretir. Bu değer varsayılan olarak SYSTEM, yani MySQL sunucu sürecinin gördüğü sistem zaman dilimidir; PHP'nin ne düşündüğünden tamamen bağımsızdır. Uygulamanız bir kaydı NOW() ile yazıp PHP tarafında date() ile okuyorsa, aynı ekranda iki farklı saat kaynağı karıştırıyorsunuz demektir.

Dördüncü katman uygulamanın kendisidir ve en sık gözden kaçan budur. WordPress, açılışta zaman dilimini kendisi UTC'ye sabitler ve gösterim sırasında Ayarlar → Genel ekranındaki tercihe göre çevirir. Laravel, config/app.php içindeki timezone değerini kullanır ve varsayılanı UTC'dir. Bu iki durumda php.ini dosyasını değiştirmeniz ekranı zerre kadar değiştirmez; çünkü uygulama sizin ayarınızı çalışma anında eziyordur.

Hangi Katman Bozuk? Dört Soruluk Teşhis Testi#

Tahmin yürütmek yerine ölçün. Aşağıdaki dört kontrolü sırayla yapın ve sonuçları bir kenara not edin; hangi satırın diğerlerinden ayrıştığı, düzeltmeniz gereken katmanı doğrudan gösterir.

1. Sistem saati ve zaman dilimi. SSH erişiminiz varsa:

timedatectl
date
date -u

Local time ile Universal time arasındaki farkın 3 saat olması ve Time zone satırının Europe/Istanbul (+03, +0300) görünmesi beklenir. NTP service: active değilse saat zamanla kayar.

2. PHP'nin gördüğü zaman dilimi. Sitenizin köküne geçici bir dosya bırakın:

<?php
echo 'PHP zaman dilimi : ' . date_default_timezone_get() . PHP_EOL;
echo 'PHP yerel saat   : ' . date('Y-m-d H:i:s') . PHP_EOL;
echo 'PHP UTC saati    : ' . gmdate('Y-m-d H:i:s') . PHP_EOL;
echo 'ini date.timezone: ' . var_export(ini_get('date.timezone'), true) . PHP_EOL;

ini_get boş dize dönerse date.timezone hiç tanımlanmamış demektir ve PHP UTC kullanıyordur. İşiniz bitince bu dosyayı silin; sunucu bilgisi sızdıran geçici dosyalar unutulmaya çok yatkındır.

3. MySQL'in gördüğü zaman dilimi. phpMyAdmin'in SQL sekmesinden veya mysql istemcisinden çalıştırın:

SELECT @@global.time_zone   AS genel_tz,
       @@session.time_zone  AS oturum_tz,
       NOW()                AS mysql_simdi,
       UTC_TIMESTAMP()      AS mysql_utc,
       TIMEDIFF(NOW(), UTC_TIMESTAMP()) AS fark;

fark sütunu 03:00:00 değilse veritabanı UTC ya da başka bir dilimle çalışıyordur. Sorguyu phpMyAdmin üzerinden çalıştırdığınızda gördüğünüz oturum, uygulamanızın açtığı oturumdan farklı olabilir; bağlantı mantığı için phpMyAdmin kullanımı yazısına göz atın.

4. Uygulamanın kendi ayarı. WordPress'te Ayarlar → Genel → Zaman Dilimi; Laravel'de config/app.php içindeki timezone; özel yazılmış bir projede genellikle bir config.php ya da .env satırı. Buradaki değer neyse, ekranda gördüğünüz odur.

Sonuçları yorumlama#

• Sadece 2. test UTC gösteriyorsa: date.timezone ayarlanmamış, PHP katmanını düzeltin.
• Sadece 3. test kayıyorsa: veritabanı oturum zaman dilimi, NOW() ile yazılan kayıtları etkiliyor.
• 1, 2 ve 3 doğru ama ekran hâlâ yanlışsa: uygulama katmanı sizin ayarınızı eziyor.
• Hepsi üç saat geride ve sistem saati de UTC ise: en temiz çözüm sistemi değil, gösterim katmanını düzeltmektir.

Sunucu Saatini Kontrol Etmek ve Düzeltmek#

Kendi VDS veya fiziksel sunucunuz varsa sistem zaman dilimini timedatectl ile yönetirsiniz:

# Kullanılabilir dilimler arasında arama
timedatectl list-timezones | grep -i istanbul

# Zaman dilimini ayarla
sudo timedatectl set-timezone Europe/Istanbul

# NTP eşitlemesini aç
sudo timedatectl set-ntp true
timedatectl status

systemd-timesyncd yerine chrony kullanan dağıtımlarda eşitlemenin gerçekten çalıştığını şöyle doğrularsınız:

chronyc tracking
chronyc sources -v

Burada önemli bir tercih var: birçok sistem yöneticisi sunucuyu bilinçli olarak UTC'de bırakır. Farklı ülkelere hizmet veren, log toplayan veya birden fazla sunucuyu karşılaştırmalı inceleyen kurulumlarda bu doğru karardır; iki sunucunun kayıt dosyasını yan yana koyduğunuzda saat kaymasıyla uğraşmazsınız. Bu durumda sistemi değiştirmeyin, sadece PHP ve gösterim katmanını Türkiye saatine ayarlayın.

Paylaşımlı hosting kullanıyorsanız sistem zaman dilimine zaten dokunamazsınız; sunucu genellikle UTC'dedir ve bu normaldir. Sizin müdahale alanınız PHP ve uygulama katmanıdır. Zamanlanmış görevlerin hangi saate göre tetiklendiğini merak ediyorsanız Linux cron görevleri yazısı cron'un sistem saatini esas aldığını hatırlatır: sunucu UTC ise 0 9 * * * satırı Türkiye saatiyle 12:00'de çalışır.

PHP date.timezone Ayarı Nasıl Yapılır?#

PHP tarafında dört farklı müdahale noktası var. Hangisinin geçerli olacağı, PHP'nin sunucuda nasıl çalıştırıldığına bağlıdır.

php.ini üzerinden (kalıcı ve doğru yöntem). Sunucu yönetimi sizdeyse önce aktif ini dosyasını bulun:

php --ini | grep "Loaded Configuration"

Dosyada [Date] bölümüne şu satırı ekleyin veya başındaki noktalı virgülü kaldırın:

[Date]
date.timezone = Europe/Istanbul

Ardından PHP-FPM kullanıyorsanız servisi yeniden başlatın (systemctl restart php8.3-fpm gibi). Değişikliğin gerçekten yüklendiğini php -i | grep date.timezone ile veya bir phpinfo() sayfasıyla doğrulayın. Bu dosyanın yapısı ve diğer yaygın direktifler için php.ini ayarları yazısına bakabilirsiniz.

cPanel'de MultiPHP INI Editor. Paylaşımlı hostingte en pratik yol budur: cPanel → Yazılım → MultiPHP INI Editor → alan adınızı seçin → "Editor Mode" sekmesinde date.timezone = Europe/Istanbul satırını ekleyip kaydedin. Bu işlem hesabınızın kökündeki ini dosyasına yazar ve yalnızca sizin sitenizi etkiler. PHP sürümüne göre farklı ini dosyalarının devreye girebileceğini unutmayın; sürüm geçişlerinin ayrıntısı PHP sürüm yönetimi yazısında.

.user.ini dosyasıyla. PHP, FastCGI/FPM olarak çalışıyorsa sitenizin kök dizinine bir .user.ini dosyası koyup içine aynı satırı yazabilirsiniz:

date.timezone = Europe/Istanbul

Bu dosya varsayılan olarak 300 saniyede bir yeniden okunur, yani değişiklik anında yansımayabilir; sabırsızlanıp defalarca düzenlemeyin.

Kod içinden. Ayar dosyasına erişemiyorsanız veya tek bir betiği düzeltmek istiyorsanız, uygulamanın ilk çalışan satırlarında zaman dilimini kendiniz belirleyin:

date_default_timezone_set('Europe/Istanbul');

Bu en taşınabilir yöntemdir ve projeyi başka bir sunucuya taşıdığınızda ayarın peşinden gitmenizi gerektirmez. Birçok çatı zaten bunu yapar.

Dikkat: .htaccess içine php_value date.timezone Europe/Istanbul yazmak yalnızca PHP, Apache modülü (mod_php) olarak çalışırken işe yarar. PHP-FPM veya CGI/FastCGI altında bu satır 500 Internal Server Error üretir. LiteSpeed sunucular bir istisnadır ve bu satırı okuyabilir. Hangi modda olduğunuzu bilmiyorsanız .user.ini yolunu tercih edin; hata alırsanız PHP hata raporlama yazısındaki adımlarla gerçek nedeni görebilirsiniz.

MySQL NOW() Neden Farklı Saat Döndürüyor?#

MySQL'in varsayılan time_zone değeri SYSTEM'dir. Sunucu UTC'deyse NOW() de UTC üretir; PHP tarafını Europe/Istanbul yapmanız buna hiçbir etki etmez. INSERT ... VALUES (NOW()) ile yazılan her satır üç saat geride kaydedilmeye devam eder.

En doğrudan çözüm, bağlantı açılır açılmaz oturumun zaman dilimini sabitlemektir. PDO ile:

$pdo = new PDO(
    'mysql:host=localhost;dbname=ornek;charset=utf8mb4',
    'kullanici',
    'parola',
    [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+03:00'",
    ]
);

mysqli kullanıyorsanız bağlantıdan hemen sonra tek satır yeterlidir:

$mysqli->query("SET time_zone = '+03:00'");

Sunucu genelinde ayarlamak isterseniz ve root erişiminiz varsa my.cnf içine yazabilirsiniz:

[mysqld]
default-time-zone = '+03:00'

'Europe/Istanbul' gibi isimli bir dilim kullanmak isterseniz MySQL'in zaman dilimi tablolarının dolu olması gerekir; boşsa bu değer kabul edilmez:

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

Yükleme sonrası kontrol:

SELECT COUNT(*) FROM mysql.time_zone_name;
SET time_zone = 'Europe/Istanbul';
SELECT NOW();

TIMESTAMP ile DATETIME arasındaki kritik fark#

Bu ayrım, saat sorunlarının en kafa karıştırıcı kısmıdır. TIMESTAMP sütunları veriyi diskte her zaman UTC olarak tutar ve okurken oturumun zaman dilimine çevirir. DATETIME sütunları ise ne verirseniz onu saklar, hiçbir çeviri yapmaz.

Sonuç şu: TIMESTAMP sütunlarında oturum zaman dilimini düzeltmeniz eski kayıtları da doğru göstermeye başlar, çünkü veri zaten UTC'ydi. DATETIME sütunlarında ise ayarı düzeltmek yalnızca bundan sonraki kayıtları etkiler; geçmişte yanlış yazılmış değerler olduğu gibi kalır. Bu iki durumu karıştırmak, "ayarı düzelttim ama eski yorumlar hâlâ yanlış" şikâyetinin birebir kaynağıdır. Sütun tiplerini görmek için MySQL veritabanı yönetimi yazısındaki DESCRIBE kullanımına bakabilirsiniz.

Uygulama Kendi Saatini Kullanıyorsa Ne Yapmalı?#

WordPress. WordPress, çalışma anında PHP'nin zaman dilimini UTC'ye sabitler ve gösterim sırasında kendi ayarına göre çevirir. Bu yüzden php.ini düzenlemek WordPress ekranlarını değiştirmez. Doğru yer Ayarlar → Genel → Zaman Dilimi kutusudur; buradan "İstanbul" şehir seçeneğini seçin, UTC+3 sabitini değil. Şehir seçimi ileride bir kural değişirse otomatik uyum sağlar. Yazı tarihleri post_date (yerel) ve post_date_gmt (UTC) olmak üzere iki sütunda tutulur; eklentiler genelde ikincisini esas alır.

Laravel. config/app.php içindeki satırı düzenleyin ve ardından yapılandırma önbelleğini temizleyin:

'timezone' => 'Europe/Istanbul',

php artisan config:clear

Laravel'i UTC'de bırakıp yalnızca görünüm katmanında ->setTimezone('Europe/Istanbul') ile çevirmek çok daha sağlıklı bir tercihtir; nedenini bir sonraki bölümde açıklıyorum.

Özel yazılmış projeler. Kod tabanında date_default_timezone_set çağrısını arayın. Birden fazla yerde çağrıldığını görmek şaşırtıcı derecede yaygındır; son çağrı kazanır ve kimse bunu fark etmez.

grep -rn "date_default_timezone_set" . --include="*.php"

Doğru Yaklaşım: Veriyi UTC Sakla, Görüntülerken Çevir#

Buraya kadar anlatılanlar bir yangını söndürür, ama yangının çıkmasını engellemez. Kalıcı çözüm bir kural belirlemektir: veritabanına her zaman UTC yaz, kullanıcıya gösterirken çevir.

Bunun üç somut faydası var. Birincisi, sunucu taşırsanız veya hosting sağlayıcınız sistem zaman dilimini değiştirirse verileriniz etkilenmez. İkincisi, yurt dışından da müşteriniz olduğunda aynı kaydı herkesin kendi saatinde göstermek tek satırlık bir iş olur. Üçüncüsü, iki tarih arasındaki farkı hesaplarken yaz saati geçişleri gibi tuzaklara takılmazsınız.

Uygulaması PHP tarafında oldukça sade:

// Yazarken: her zaman UTC
$simdiUtc = (new DateTimeImmutable('now', new DateTimeZone('UTC')))
    ->format('Y-m-d H:i:s');

$stmt = $pdo->prepare('INSERT INTO siparisler (created_at) VALUES (?)');
$stmt->execute([$simdiUtc]);

// Okurken: kullanıcının dilimine çevir
$kayit = new DateTimeImmutable($satir['created_at'], new DateTimeZone('UTC'));
echo $kayit->setTimezone(new DateTimeZone('Europe/Istanbul'))
           ->format('d.m.Y H:i');

Bu düzende NOW() kullanmaktan kaçınırsınız; zaman damgasını her zaman uygulama üretir ve tek bir kaynak olur. SQL tarafında üretmek zorundaysanız NOW() yerine UTC_TIMESTAMP() kullanın.

Yeni bir projeye başlıyorsanız kural nettir: sütunları DATETIME yapın, değerleri UTC yazın, TIMESTAMP tipini yalnızca 2038 sınırı sorun olmayacak, otomatik güncellenen alanlar için tercih edin.

Kaydedilmiş Yanlış Saatleri Toplu Düzeltmek#

Ayarı düzelttiniz ama geçmişte üç saat eksik yazılmış binlerce kaydınız var. Bunları toplu kaydırabilirsiniz; ancak önce iki şeyi kesinleştirin: kaç saatlik kayma olduğunu ve hangi tarihten sonraki kayıtların zaten doğru olduğunu. Ayarı düzelttiğiniz andan sonraki kayıtları da kaydırırsanız bu kez üç saat ileri giderler.

Her zaman önce yedek alın. Ardından değişikliği bir SELECT ile prova edin:

-- Önce ne olacağını görün
SELECT id, created_at, DATE_ADD(created_at, INTERVAL 3 HOUR) AS yeni_deger
FROM yorumlar
WHERE created_at < '2026-08-18 00:00:00'
LIMIT 20;

-- Sonuç doğruysa uygulayın
UPDATE yorumlar
SET created_at = DATE_ADD(created_at, INTERVAL 3 HOUR)
WHERE created_at < '2026-08-18 00:00:00';

TIMESTAMP tipindeki sütunlarda bu işlemi yapmayın; oradaki veri zaten UTC'dir ve kaydırırsanız gerçekten bozulur. Yedek almadan çalıştırılan bir UPDATE geri alınamaz.

Yaz Saati, Türkiye ve +03 Sabiti Arasındaki Fark#

Türkiye 2016'dan bu yana yaz saati uygulamıyor; yıl boyunca UTC+3'te sabit. Bu yüzden Europe/Istanbul ile +03:00 bugün aynı sonucu verir ve pek çok kişi ikisini eşdeğer sanır. Aralarındaki fark geleceğe dairdir: Europe/Istanbul bir kural adıdır, +03:00 ise bir sayıdır. Kural değişirse isimli dilimi kullanan sistemler zaman dilimi veritabanı güncellendiğinde kendiliğinden uyum sağlar; sabit ofset yazanlar elle düzeltilmeyi bekler.

Ayrıca 2016 öncesine ait tarihlerle çalışıyorsanız fark bugün de vardır: Europe/Istanbul o dönemdeki yaz saati geçişlerini bilir ve doğru çevirir, +03:00 bilmez. Arşiv verisi, muhasebe kayıtları veya erişim kaydı analizi gibi geçmişe dokunan işlerde bu ayrım gerçek bir hataya dönüşür.

Pratik öneri: PHP ve uygulama katmanında isimli dilim kullanın. MySQL tarafında zaman dilimi tablolarını yükleyebiliyorsanız orada da isim kullanın; yükleyemiyorsanız +03:00 sabiti kabul edilebilir bir taviz, çünkü verinin kendisi zaten UTC olmalı.

Son bir alışkanlık edinin: PHP sürümünü yükselttiğinizde veya hosting paketinizi taşıdığınızda yukarıdaki dört testi tekrar çalıştırın. Yeni sürümle birlikte yüklenen php.ini çoğu zaman varsayılan haliyle gelir ve date.timezone satırı yeniden yorum satırına dönmüş olabilir. Bu, sürüm geçişlerinden sonra ortaya çıkan "dün çalışıyordu" vakalarının sessiz sebeplerinden biridir.

Sıkça Sorulan Sorular#

PHP zaman dilimini değiştirdim ama site hâlâ eski saati gösteriyor, neden?#

En olası üç sebep var. Birincisi, PHP-FPM kullanıyorsanız servisi yeniden başlatmadınız; ini değişikliği ancak süreç yeniden doğduğunda okunur. İkincisi, uygulamanız sizin değerinizi çalışma anında kendi ayarıyla eziyor. Üçüncüsü, tarihler NOW() ile veritabanı tarafında üretiliyor ve PHP ayarı bu değere hiç dokunmuyor. Teşhis bölümündeki dört kontrolü sırayla çalıştırmak hangisinin geçerli olduğunu birkaç dakikada gösterir.

Sunucu saatini Türkiye saatine almak yerine UTC'de bırakmak doğru mu?#

Çok yaygın ve savunulabilir bir tercihtir. Birden fazla sunucunuz varsa, farklı ülkelerden ziyaretçi alıyorsanız veya kayıt dosyalarını karşılaştırmalı inceliyorsanız sistemi UTC'de tutmak işinizi kolaylaştırır. Bu durumda sistem saatine dokunmaz, yalnızca PHP ve uygulama katmanını Türkiye saatine ayarlarsınız. Paylaşımlı hostingte zaten sistem zaman dilimini değiştirme yetkiniz olmaz.

MySQL zaman dilimi tablolarını yüklemeden isimli dilim kullanabilir miyim?#

Hayır. SET time_zone = 'Europe/Istanbul' komutu, mysql.time_zone_name tablosu boşsa bilinmeyen zaman dilimi hatası verir. Tabloları mysql_tzinfo_to_sql aracıyla doldurmanız gerekir; buna yetkiniz yoksa +03:00 biçiminde sabit ofset kullanabilirsiniz. Türkiye yaz saati uygulamadığı için bu iki değer bugün aynı sonucu üretir.

Eski kayıtlardaki yanlış saatleri düzeltmeli miyim?#

Sütun tipine bağlı. TIMESTAMP sütunlarında veri zaten UTC saklandığı için ayarı düzeltmeniz eski kayıtları da doğru göstermeye başlar; hiçbir şey yapmanıza gerek yoktur, hatta müdahale ederseniz bozarsınız. DATETIME sütunlarında ise geçmiş değerler olduğu gibi kalır ve toplu kaydırma gerekebilir. Her durumda önce yedek alın ve değişikliği bir SELECT sorgusuyla prova edin.

Cron görevlerim yanlış saatte çalışıyor, bunun zaman dilimiyle ilgisi var mı?#

Doğrudan ilgisi var. Cron, PHP'nin değil işletim sisteminin zaman dilimini kullanır. Sunucu UTC'deyse 0 9 * * * satırı Türkiye saatiyle 12:00'de tetiklenir. Ya cron satırındaki saati üç saat geri alın, ya crontab dosyasının başına CRON_TZ=Europe/Istanbul satırı ekleyin, ya da sistem zaman dilimini değiştirin.

phpMyAdmin'de doğru saati görüyorum ama sitemde yanlış, sebebi ne olabilir?#

phpMyAdmin veritabanına kendi bağlantısını açar ve bu bağlantının oturum zaman dilimi, uygulamanızın açtığı bağlantıdan farklı olabilir. Ayrıca phpMyAdmin TIMESTAMP sütunlarını kendi oturumuna göre çevirerek gösterir. Bu yüzden phpMyAdmin ekranı doğruyu söylüyor diye veritabanı katmanını temize çıkarmayın; teşhis sorgusunu uygulamanızın kullandığı kullanıcıyla çalıştırın.

Zaman dilimi ayarı yaptığım halde e-posta bildirimlerindeki saat farklı çıkıyor?#

E-posta şablonları çoğu zaman uygulamanın gösterim katmanından değil, doğrudan veritabanı değerinden veya ayrı bir servisten beslenir. Ayrıca gönderilen iletinin Date başlığını PHP değil, çoğu kurulumda posta sunucusu yazar ve o kendi sistem zaman dilimini kullanır. Şablonu inceleyip tarihin nereden geldiğini bulun; ideal çözüm yine aynı: değeri UTC olarak taşıyıp yalnızca şablonda biçimlendirmek.