Unix Zaman Damgası Dönüştürücü
Unix zaman damgası ile okunabilir tarih arasında dönüşüm. Saniye mi milisaniye mi olduğunu ayırt eder, UTC ile yerel saati yan yana gösterir, 2038 sınırını işaretler.
Zaman damgasından tarihe
Şimdi düğmesi geçerli zamanı yazar ve siz yazmaya başlayana kadar saniyede bir güncellenir.
Bir zaman damgası yazın, karşılığı burada görünecek.
Tarihten zaman damgasına
Bir tarih yazın, zaman damgası burada görünecek.
Özet (TL;DR)
- JavaScript'te
new Date(1700000000)2023 değil, 20 Ocak 1970'tir:Datemilisaniye bekler, çoğu API saniye gönderir. - Hane sayısı ayrımı yapar: 10 hane saniye, 13 hane milisaniye, 16 hane mikrosaniyedir.
- 2147483647 saniye (19 Ocak 2038) işaretli 32 bit
time_t'nin sınırıdır; bu araç sınırı aşan değerleri uyarı olarak bildirir. - Timestamp mutlak bir andır, saat dilimi taşımaz; saat dilimi yalnızca gösterimde devreye girer.
Production'da 1970 gösteren tarih
Sipariş listesinde bütün tarihler 20 Ocak 1970 görünüyor. Veritabanına bakıyorsunuz, kayıtlar doğru. API yanıtına bakıyorsunuz, sayı doğru. Arada tek bir çarpma eksik: gelen değer saniye cinsinden ama new Date() milisaniye bekliyor, yani 1.7 milyar milisaniye epoch'tan yaklaşık yirmi gün sonrasına düşüyor. Bu hatanın en can sıkıcı tarafı hiçbir yerde hata fırlatmaması, tarih geçerli bir tarih, sadece yanlış.
Saniye mi milisaniye mi
Unix timestamp'i geleneksel olarak 1 Ocak 1970 UTC'den itibaren geçen saniye sayısıdır. Unix araçları, Postgres'in EXTRACT(EPOCH ...) çıktısı, JWT'nin exp ve iat alanları, Stripe gibi pek çok API saniye kullanır. JavaScript ise Date.now() ile milisaniye üretir ve new Date() yapıcısı da milisaniye bekler. İki dünya arasındaki bin katlık fark, hazır bir tarih kütüphanesi kullanmadığınız her yerde karşınıza çıkar.
const gelen = 1700000000; // API saniye gonderdi new Date(gelen).toISOString();// '1970-01-20T16:13:20.000Z' <-- yanlış, 20 gün sonrası new Date(gelen * 1000).toISOString();// '2023-11-14T22:13:20.000Z' <-- doğru // Ters yon: Date'ten saniyeyeMath.floor(Date.now() / 1000);Ayırt etmenin pratik yolu hane saymak. Bugünlerde saniye cinsinden bir timestamp 10 hane (1000000000 değeri 9 Eylül 2001'e denk gelir ve 9999999999 değeri 2286 yılına kadar gider), milisaniye 13 hane, mikrosaniye 16 hanedir. ClickHouse, Postgres ve Chrome trace kayıtları mikrosaniye üretir. Bu araç girdiyi hane sayısına göre sınıflandırıp hangi birim olarak yorumladığını açıkça yazar, yani tahmin sizde kalmaz.
| Hane sayısı | Birim | Örnek | Karşılığı |
|---|---|---|---|
| 10 | Saniye | 1700000000 | 14 Kasım 2023 |
| 13 | Milisaniye | 1700000000000 | 14 Kasım 2023 |
| 16 | Mikrosaniye | 1700000000000000 | 14 Kasım 2023 |
| 9 ve altı | Saniye | 86400 | 2 Ocak 1970 |
| 20 ve üstü | Tahmin edilmiyor | 17000000000000000000 | Muhtemelen nanosaniye veya kimlik |
2038 problemi
İşaretli 32 bitlik bir time_t en fazla 2147483647 saniyeyi tutabilir, bu da 19 Ocak 2038 saat 03:14:07 UTC demek. Bir saniye sonrasında sayı taşar ve 1901 yılına döner. JavaScript'in bu sınırla derdi yok, sayıları çok daha geniş bir aralıkta tutuyor; sorun tarayıcıda çalışan değerin backend'e ulaştığı yerde çıkıyor. Eski C kodu, gömülü sistemler ve MySQL'in TIMESTAMP sütunu (DATETIME değil) bu sınıra tabi.
Uyarı
Saat dilimleri ve depolama
Timestamp mutlak bir andır ve içinde saat dilimi bilgisi yoktur. 1700000000 değeri İstanbul'da da Tokyo'da da aynı anı gösterir, yalnızca o an ekranda farklı saatlerle yazılır. Buradan çıkan kural basit: zamanı UTC olarak saklayın, kullanıcının yerel saatine yalnızca gösterim aşamasında çevirin. Yerel saati veritabanına yazarsanız yaz saati geçişlerinde tekrar eden ve hiç yaşanmayan saatlerle uğraşırsınız. Aynı sebeple ISO 8601 metinlerinde sondaki Z harfini ya da açık +03:00 farkını atlamayın; ofissiz bir tarih metnini her sistem kendi yerel dilimine göre okur.
Epoch öncesi tarihler negatif timestamp ile ifade edilir: -86400 değeri 31 Aralık 1969'dur. Burada da bir tuzak var, çünkü bazı sistemler time_t'yi işaretsiz saklar ve aynı biti 2106 yılı olarak okur. Araç negatif değerleri de ayrı bir uyarıyla bildiriyor. Bir başka ince nokta: Unix zamanı artık saniyeleri temsil etmez, her günü tam 86400 saniye kabul eder, dolayısıyla iki timestamp arasındaki fark gerçek geçen süreden birkaç saniye sapabilir.
Sıkça Sorulan Sorular
- Tarihim neden 1970 gösteriyor?
- Neredeyse her zaman saniye cinsinden bir değeri milisaniye bekleyen bir yere verdiğinizden olur. 1.7 milyar milisaniye, epoch'tan yaklaşık yirmi gün sonrasıdır. Değeri 1000 ile çarpın veya bu araca yapıştırıp hangi birimde olduğuna bakın.
- Timestamp'im saniye mi milisaniye mi?
- Hane sayın. 10 haneli bir sayı saniye, 13 haneli bir sayı milisaniyedir. Emin olamıyorsanız değeri her iki şekilde de çevirip hangisinin makul bir tarih verdiğine bakın; yanlış olan ya 1970 civarına ya da binlerce yıl ötesine düşer.
- 2038 problemi tam olarak nedir?
- İşaretli 32 bit bir tamsayı en fazla 2147483647 saniye tutabilir, bu da 19 Ocak 2038'e denk gelir. Bir saniye sonra değer taşar ve 1901 yılına döner. 64 bitlik sistemler etkilenmez ama eski C kodu, gömülü cihazlar ve MySQL TIMESTAMP sütunları hâlâ bu sınıra tabi.
- Timestamp saat dilimi bilgisi taşır mı?
- Taşımaz. Timestamp, UTC epoch'tan itibaren geçen süredir ve dünyanın her yerinde aynı anı gösterir. Saat dilimi yalnızca o anı insana gösterirken devreye girer. Zamanı UTC saklayıp yerel saate gösterim anında çevirmek bu yüzden doğru yaklaşımdır.
- Şu anki timestamp'i nasıl alırım?
- JavaScript'te milisaniye için
Date.now(), saniye içinMath.floor(Date.now() / 1000). Python'daint(time.time()), terminaldedate +%s, PostgreSQL'deEXTRACT(EPOCH FROM now()). Bu sayfadaki alan da anlık değeri gösterir.