Bir kayıtta zaman üç ayrı görünümde karşımıza çıkar: 1790510400 gibi bir sayı, 2026-09-27T12:00:00Z gibi farkı yazılmış bir metin ya da Sep 27 15:00:00 gibi yalnızca duvar saati. Üçü de aynı anı gösterebilir. Bizce iki kaydı yan yana koymadan önce sorulması gereken ilk soru budur: bu saat hangi saate göre?
Bu yazı zaman damgalarının nasıl tutulduğunu, UTC ile Türkiye saati arasındaki farkın tarihçesini, sistem saatlerinin neden kaydığını ve bunların korelasyonda nasıl hataya dönüştüğünü anlatıyor. Değerleri çevirmek için zaman damgası dönüştürücüyü kullanabilirsiniz; hesap tarayıcınızda yapılır.
Dijital kayıtlarda zaman nasıl tutulur?
Zaman üç biçimde yazılır ve her birinin kendi riski vardır.
- Başlangıç noktasından sayılan değer (epoch)
- Sistem sabit bir başlangıçtan bu yana geçen süreyi sayar: Unix 1 Ocak 1970'ten saniye, Windows FILETIME 1 Ocak 1601'den 100 nanosaniyelik aralık, Apple'ın Cocoa zamanı 1 Ocak 2001'den saniye. Bu değerler tanım gereği UTC'dir; saat dilimi sorunu değeri okunur tarihe çevirirken çıkar. Birim ise değerin kendisinde yazmaz, aynı uygulamada bir alan saniye, diğeri milisaniye olabilir.
- Farkıyla birlikte yazılan tarih
2026-09-27T15:00:00+03:00(ISO 8601, RFC 3339) ya da Apache'nin[27/Sep/2026:15:00:00 +0300]biçimi. UTC'ye göre fark satırın içindedir;Zfarkın sıfır olduğunu gösterir. En güvenilir biçim budur, ama fark bilgisi kayıt başka bir tabloya aktarılırken kolayca düşer. RFC 6302'nin sunucu logları için yerel saat yerine UTC önermesinin gerekçesi de budur.- Farkı yazılmayan yerel saat
- EXIF'teki
DateTimeOriginal, FAT dosya sistemi tarihleri, eski tip syslog (RFC 3164) satırları, çoğu Excel tablosu. Değer bir duvar saatidir; hangi bölgeye ait olduğu başka bir alandan, cihaz ayarından ya da bağlamdan çıkarılır ve bu çıkarım raporda varsayım olarak yazılır. RFC 3164 satırında yıl da yoktur.
Aynı an, yani 27 Eylül 2026 12:00:00 UTC (Türkiye saatiyle 15:00), farklı biçimlerde şöyle görünür:
| Biçim | Başlangıç ve birim | Değer |
|---|---|---|
| Unix | 1970-01-01 UTC, saniye | 1790510400 |
| Unix (milisaniye) | 1970-01-01 UTC, ms | 1790510400000 |
| Windows FILETIME | 1601-01-01 UTC, 100 ns | 134349840000000000 |
| WebKit / Chrome | 1601-01-01 UTC, µs | 13434984000000000 |
| Apple Cocoa | 2001-01-01 UTC, saniye | 812203200 |
| HFS+ | 1904-01-01 GMT, saniye | 3873355200 |
| GPS | 1980-01-06, hafta ve haftanın saniyesi; artık saniye eklenmez | hafta 2438, 43218 s |
| RFC 3339 metni | farkıyla | 2026-09-27T12:00:00Z |
| RFC 3164 syslog, Türkiye'deki bir cihaz | yerel saat, yıl yok | Sep 27 15:00:00 |
Günümüz tarihleri için basamak sayısı iyi bir ipucudur: 10 hane genellikle Unix saniyesi, 13 hane milisaniye, 17 hane WebKit değeridir. Bu yine de bir tahmindir; birim, aynı kaynaktan zamanı bilinen bir test kaydıyla doğrulanmalıdır.
UTC ile Türkiye saati arasında kaç saat fark var?
Bugün 3 saat. Türkiye saati UTC+3'tür ve yıl boyu değişmez. 27 Mart 2016'da ileri alınan saat, 8 Eylül 2016 tarihli ve 29825 sayılı Resmî Gazete'de yayımlanan 2016/9154 sayılı Bakanlar Kurulu Kararı'yla bir daha geri alınmadı. Daha eski kayıtlarda fark mevsime göre 2 ya da 3 saattir:
| Dönem | UTC'ye göre fark | Not |
|---|---|---|
| 1985–2006 | Kışın +2, yazın +3 | Geçiş günleri ve saatleri yıllara göre değişti; o yılın kuralı IANA tz kaydından alınır |
| 2007–2015, genel kural | Kışın +2, yazın +3 | Geçişler Avrupa ile aynı: Mart ve Ekim'in son pazarı, 01:00 UTC |
| 2011 | Kışın +2, yazın +3 | Yaz saatine 27 yerine 28 Mart'ta geçildi; 27 Mart'ta ülke çapında bir sınav vardı |
| 2014 | Kışın +2, yazın +3 | Yaz saatine 30 yerine 31 Mart'ta geçildi; gerekçe yerel seçimdi |
| 2015 | Kışın +2, yazın +3 | Kış saatine 25 Ekim yerine 8 Kasım'da dönüldü |
| 27 Mart 2016'dan beri | +3 | 7 Eylül 2016'dan itibaren kalıcı; Ekim 2017'de alınan yaz-kış uygulamasına dönüş kararı Kasım 2017'de geri alındı |
Tarih de kayabilir. Örnek: 15 Ocak 2014 21:30 UTC, Türkiye saatiyle 23:30'dur. Sabit +3 eklenirse 16 Ocak 00:30 çıkar ve olay başka bir güne yazılır.
2016 öncesinde yaz saatine geçilen gece yerel saat 03:00'ten 04:00'e atlıyordu; o gece yerel saatle 03:00–03:59 yazan bir kayıt olağan değildir. Kış saatine dönülen gece ise 04:00'te saat 03:00'e alındığı için bu aralık iki kez yaşandı. Örnek: 26 Ekim 2014'te yerel saatle 03:30 yazan, farkı belirtilmemiş bir kayıt 00:30 UTC'yi de 01:30 UTC'yi de gösterebilir. Başka bir kaynakla çözülemiyorsa bu belirsizlik raporda yazılır.
Resmî saat ile cihazın gösterdiği saat aynı olmayabilir
IANA saat dilimi veri tabanının Türkiye notlarına göre 2014'teki geç geçişe seçim görevlileri uydu, cep telefonları uymadı; telefonlar saati Avrupa takvimiyle bir gün erken ileri aldı. 2015'te de otomatik ayarlı saatler resmî karara rağmen 25 Ekim'de geri gitti ve 8 Kasım'a kadar resmî saatin bir saat gerisinde kaldı. Güncellenmemiş saat dilimi verisi taşıyan cihazların 30 Ekim 2016'da saati yanlışlıkla geri almış olması da ihtimal dahilindedir.
Buradaki ince nokta şudur: dönüştürücüler, bizimki dahil, resmî kuralı uygular. O günlerde bir telefonun ekranda ve kendi kayıtlarında gerçekte hangi saati kullandığı ayrıca sınanmalıdır; yerel saatle yazılmış cihaz kayıtları ile resmî saate göre tutulmuş kayıtlar arasında bir saatlik fark beklenebilir.
Hangi kayıt hangi saati yazar?
Tablo sık karşılaştığımız kaynakların varsayılan davranışını gösterir. Yapılandırma değiştirilebilir; incelemede her kaynak ayrıca doğrulanır.
| Kaynak | Yazılan saat | Dikkat |
|---|---|---|
| NTFS dosya zamanları | UTC (FILETIME) | Dosya Gezgini yerel saate çevirerek gösterir. |
| FAT32 biçimli USB bellek, hafıza kartı | Yerel saat, fark yok | Değiştirme zamanı 2 saniye çözünürlüklüdür. Değer, dosyayı yazan cihazın o anki saat ayarını taşır. |
| exFAT | Yerel saat ve UtcOffset alanı | Fark alanı geçerli işaretlenmişse UTC'ye çevrilebilir. |
| Windows olay günlüğü (EVTX) | UTC (TimeCreated SystemTime) | Olay Görüntüleyici ekranda yerel saat gösterir. |
| Linux journald | UTC, mikrosaniye | __MONOTONIC_TIMESTAMP yalnızca aynı açılış (_BOOT_ID) içinde anlamlıdır. |
| Eski tip syslog (RFC 3164) | Yerel saat; yıl ve fark yok | Router, switch ve modemlerde sık görülür. |
| Syslog (RFC 5424) | RFC 3339 metni, farkıyla ya da Z | En fazla mikrosaniye; artık saniye kullanılmaz. |
| Apache, Nginx erişim logu | Yerel saat ve fark (+0300) | Apache'de %t isteğin alındığı an, Nginx'te $msec logun yazıldığı andır. |
E-posta Received: satırları | Yerel saat ve sayısal fark | Her sunucu kendi saatini yazar; satırlar UTC'ye çevrilerek sıralanır. |
EXIF DateTimeOriginal | Yerel saat, fark yok | Fark için OffsetTimeOriginal (Exif 2.31, 2016) gerekir; GPSTimeStamp ise UTC'dir. |
| Operatör dökümleri (HTS, internet oturumları) | Çoğu zaman belgede yazmaz | BTK'nın İSS trafik logu dokümanı Türkiye yerel saatini esas alır. SWGDE'ye göre operatörler dökümü cihazın bulunduğu yerin, santralin ya da merkezin saatiyle veya sıklıkla UTC ile verebilir. |
Fotoğraflardaki zaman alanları için EXIF verisi yazısına bakabilirsiniz.
Sistem saatleri neden kayar?
Her bilgisayarın, telefonun ve ağ cihazının kendi saati vardır ve hiçbiri tam doğru işlemez. NTP'nin (Network Time Protocol) dördüncü sürümünü tanımlayan RFC 5905, bir saatin frekans toleransını 15 ppm (milyonda 15) olarak varsayar. Buna göre eşitlenmeyen bir saat günde yaklaşık 1,3 saniye, bir yılda 8 dakikaya yakın sapabilir. Pili bitmiş bir anakart saati ya da elle yanlış kurulmuş bir kayıt cihazı ise saatlerce geride durabilir.
Bu yüzden NIST'in log yönetimi rehberi (SP 800-92) log üreten bütün sistemlerin saatinin ortak bir kaynağa eşitlenmesini ister; eşitlenmemiş kaynaklarda zamanlara ekleme ya da çıkarma yapmak gerekebileceğini de kabul eder. BTK da İSS'lerden bütün cihazlarının en az bir NTP sunucusundan zaman almasını istemektedir.
Bir kaynağın saatinin olay tarihinde doğru olup olmadığı ancak başka bir kaynakla karşılaştırılarak ölçülebilir. İzlediğimiz adımlar:
- Aynı olayın iki kaynakta birden iz bıraktığı anlar bulunur: cihazdan gönderilen bir e-postanın cihazdaki gönderim zamanı ile alıcı sunucunun
Received:satırı, bir hesaba girişin sunucu logu ile tarayıcı geçmişindeki karşılığı, bir dosyanın bulut hizmetine yükleniş kaydı ile cihazdaki değiştirme zamanı. - Bu çapa anları arasındaki fark hesaplanır. Fark sabitse saat kaymıştır (clock skew); zamanla büyüyorsa saat sürükleniyordur (drift).
- Saatin elle ya da yazılımla değiştirildiğine dair izler aranır: Windows'ta 4616 numaralı olay (sistem saati değiştirildi; denetim alt kategorisi ayarından bağımsız olarak kaydedilir), Linux'ta
wtmpdosyasındaki saat değişikliği kayıtları, RFC 5424 syslog'da kaynağın saat güvenilirliğini bildirentimeQualityalanı (tzKnown,isSynced). - Düzeltme uygulanacaksa değeri, dayanağı ve kabul edilen tolerans raporda yazılır; özgün değerler düzeltilmiş değerlerin yanında korunur.
Korelasyonda saat farkı nasıl hataya dönüşür?
Aşağıdaki örnekler kurgusaldır; her biri incelemelerde görülen bir hata türünü gösterir.
- Tersine dönen sıra. Örnek: HTS dökümünde bir arama 14:05'te görünüyor; telefonun imajından çıkan mesajlaşma veri tabanında aynı kişiye yazılmış mesaj 11:07. Rapor aramanın mesajdan üç saat sonra yapıldığını yazıyor. Oysa veri tabanındaki değer UTC'dir ve Türkiye saatiyle 14:07'dir: mesaj aramadan iki dakika sonra yazılmıştır.
- Yanlış abone. Örnek: Platform, hesaba girişin 03.11.2025 18:42:17 UTC'de yapıldığını bildiriyor. Talep yazısına saat dilimi belirtilmeden "18:42:17" olarak geçiyor ve Türkiye saatiyle tutulan operatör kaydında üç saat öncesi sorgulanıyor. CGNAT'lı bir adreste port bloğu o arada el değiştirmişse cevap başka bir aboneyi gösterir. Mekanizma: CGNAT nedir.
- Aynı fotoğrafta iki saat. Örnek: 1 Kasım 2015 akşamı, otomatik saat ayarlı ve saat dilimi verisi güncellenmemiş bir telefonla çekilen fotoğrafın EXIF
DateTimeOriginalalanında 19:00 yazıyor,GPSTimeStampise 17:00 UTC. Resmî kurala göre bu an 20:00'dir. Telefon 25 Ekim'de saati geri almıştır; iki alan arasındaki bir saatlik fark manipülasyon değil, eski kuraldır. - Yılı olmayan satır. Örnek: Bir modemin RFC 3164 biçimli logu Ocak 2026'da dışa aktarılıyor; satırlarda
Dec 31 23:58:12veJan 1 00:03:40var. Araç yılı dışa aktarma tarihinden alırsa ilk satırı 31 Aralık 2026'ya koyar ve iki dakika arayla olan olaylar bir yıl ayrılır. - USB bellekte kaymış saatler. Örnek: FAT32 biçimli bir bellekteki dosyalar, saati UTC'ye ayarlı bir dizüstünde yazılmış. FAT yerel saati fark bilgisi olmadan tuttuğu için dosya zamanları UTC değerini taşır; bellek Türkiye saatine ayarlı bir bilgisayarda açıldığında aynı değerler yerel saat gibi okunur ve dosyalar üç saat erken yazılmış görünür. NTFS UTC tuttuğu için aynı dosyanın dizüstündeki kopyasında bu sapma yoktur.
Raporda zaman nasıl yazılmalı?
Zamanla ilgili her bulgunun başkası tarafından tekrar üretilebilmesi için raporlarımızda şu kuralları uygularız:
- Her zaman farkıyla yazılır:
2025-11-03 21:42:17 +03:00ya da18:42:17 UTC. Yalnızca "21:42" yazmak yetmez. - Her kaynağın saat referansı ve bunun nereden anlaşıldığı belirtilir: belgenin kendi beyanı, yapılandırma dosyası, test kaydı ya da çıkarım.
- Çevrilen değerin özgün hâli (ham sayı ya da metin) yanında durur; okuyan çeviriyi kendisi tekrarlayabilir.
- Kullanılan araç ve sürümü yazılır. 2014 ve 2015'teki geçiş dönemlerinde resmî kural ile cihazın fiilî davranışı ayrı ayrı değerlendirilir.
- İki kaynak eşleştirilirken kabul edilen tolerans gerekçesiyle yazılır; tolerans içinde birden fazla aday kalıyorsa hepsi gösterilir.
Farklı sistemlerin kayıtlarını tek zaman çizelgesinde birleştirmek, saat kaymasını ölçmek ya da dosyadaki bir raporun saat dönüşümlerini denetlemek gerekiyorsa bunu log analizi kapsamında yapıyoruz. Logların güvenilirliğini etkileyen diğer etkenleri (yetkili erişim, rotasyon, bütünlük) log kayıtlarının güvenilirliği yazısında ele aldık.