Tek cümlede Unix zamanı
Unix zamanı (epoch time ya da POSIX zamanı da denir), 1970-01-01T00:00:00Z anından itibaren saniye sayan tek bir tam sayıdır. İçinde saat dilimi, yaz saati ya da takvim yoktur; veritabanları, log dosyaları, API'ler, JWT token'ları ve dosya sistemleri de tam bu yüzden onu kullanır: farklı kıtalardaki iki sunucu aynı an için aynı sayıyı yazar.
1970'ten önceki tarihler negatif sayıdır: -1, 31 Aralık 1969 saat 23:59:59 UTC'dir. Bugünkü değer iki milyarın biraz altında ve her gün 86.400 artıyor.
Burada dene: Unix zaman damgası dönüştürücü
Aracın tam sayfasını açSaniye, milisaniye, mikrosaniye
Tanım saniye kullanır ama birçok sistem daha küçük birimler saklar ve yine de buna Unix zaman damgası der. 2026'da bunları ayırmanın en hızlı yolu hane sayısıdır; bu sayfadaki dönüştürücü de birimi böyle tanır.
Birimleri karıştırmak en sık yapılan hatadır: milisaniyeyi saniye sanırsan yaklaşık 54.000 yıl sonrasına bir tarih çıkar, saniyeyi milisaniye sanırsan Ocak 1970'e düşersin. Dönüşüm 1970 gösteriyorsa 1.000 ile çarp, çok uzak bir yıl gösteriyorsa 1.000'e böl.
| Birim | Bugünkü hane sayısı | Aynı an için örnek | Tipik kaynaklar |
|---|---|---|---|
| Saniye | 10 | 1700000000 | Unix ve Linux, PHP time(), MySQL UNIX_TIMESTAMP(), JWT exp ve iat |
| Milisaniye | 13 | 1700000000000 | JavaScript Date.now(), Java System.currentTimeMillis(), birçok JSON API |
| Mikrosaniye | 16 | 1700000000000000 | PostgreSQL iç yapısı, bazı Python ve veritabanı araçları |
| Nanosaniye | 19 | 1700000000000000000 | Go time.UnixNano(), yüksek çözünürlüklü izleme |
Saat dilimleri ve UTC
Zaman damgasının kendisi her zaman UTC'ye dayanır; saat dilimi ancak onu bir insanın okuyacağı takvim tarihine çevirirken devreye girer. Aynı 1700000000 değeri Londra'da 22:13, New York'ta 17:13, İstanbul'da ertesi gün 01:13'tür. Sayı değişmez, sadece gösterim değişir.
Bu yüzden doğru yöntem, zaman damgası (ya da UTC tarih) saklamak ve yerel saate en son adımda, arayüzde çevirmektir. Yerel saat saklamak, yaz saati uygulanan ülkelerde saatler değişirken çift ya da kayıp saatlere yol açar. Türkiye 2016'dan beri yıl boyu UTC+3 kullanıyor, ama yurt dışıyla çalışan sistemler için bu kural yine geçerli. Dönüştürücü her zaman damgasını yerel saatinde, UTC'de ve Şu dilimde de göster alanından seçtiğin bir dilimde gösterir; API'ler için ISO 8601 (2023-11-14T22:13:20.000Z), e-posta başlıkları için RFC 2822 biçimini de verir.
Bir ayrıntı: Unix zamanı artık saniyeleri saymaz. Her gün tam 86.400 saniyedir, bu sayede zaman damgası basit aritmetikle tarihe çevrilebilir.
Excel ve Google E-Tablolar'da dönüştürme
Tablo programları 1970'ten beri geçen saniyeyi değil, 1900'den beri geçen günü sayar. Bu yüzden bir gündeki saniye sayısına bölüp epoch tarihini eklersin. Türkçe Excel'de fonksiyon adı TARİH, ayraç noktalı virgüldür. Sonuç hücresini Tarih ya da Tarih saat olarak biçimlendir, yoksa 45244,93 gibi ondalıklı bir sayı görürsün.
Sonuç UTC'dir. Türkiye saati için 3/24 eklemen yeterli, çünkü Türkiye'de yaz saati uygulaması yok. Yaz saati olan ülkelerde sabit bir fark yılın yarısında yanlış sonuç verir; büyük loglar için dönüştürücünün toplu modunu kullan.
| İş | Formül (zaman damgası A2'de) |
|---|---|
| Saniyeden tarihe (UTC) | =A2/86400+TARİH(1970;1;1) |
| Milisaniyeden tarihe (UTC) | =A2/86400000+TARİH(1970;1;1) |
| Saniyeden Türkiye saatine (UTC+3) | =A2/86400+TARİH(1970;1;1)+3/24 |
| A2'deki tarihten saniyeye | =(A2-TARİH(1970;1;1))*86400 |
| İngilizce Excel'de aynı formül | =A2/86400+DATE(1970,1,1) |
JavaScript, Python ve SQL'de dönüştürme
Her büyük dilde ve veritabanında hazır fonksiyonlar var. Her birinin beklediği birime dikkat et: JavaScript milisaniyeyle, diğerlerinin çoğu saniyeyle çalışır.
| Ortam | Şu anki zaman damgası | Zaman damgasından tarihe |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('Y-m-d H:i:s', $ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| PostgreSQL | extract(epoch from now()) | to_timestamp(ts) |
| SQL Server | DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME()) | DATEADD(SECOND, ts, '1970-01-01') |
| SQLite | strftime('%s', 'now') | datetime(ts, 'unixepoch') |
2038 sorunu
Birçok eski sistem Unix zamanını işaretli 32 bit tam sayı olarak saklar. Bunun en büyük değeri 2.147.483.647'dir ve 19 Ocak 2038 saat 03:14:07 UTC'de (Türkiye saatiyle 06:14:07) bu değere ulaşılır. Bir saniye sonra sayı taşar, büyük bir negatif değere döner ve tarih Aralık 1901'e atlar. Geleceğe dönük tarih hesaplayan her şey, örneğin 20 yıllık krediler, sertifikalar ya da zamanlanmış işler, bu sınıra daha erken takılabilir.
Güncel işletim sistemleri, diller ve veritabanları 64 bit zaman kullanır; bu milyarlarca yıl yeter. Risk eski gömülü cihazlarda, dosya biçimlerinde ve veritabanı kolonlarındadır. Örneğin MySQL'de TIMESTAMP kolon tipi hâlâ Ocak 2038'de biter; uzun ömürlü veriyi DATETIME ya da BIGINT kolonda tutmak daha güvenli. Eski bir kodun bakımını yapıyorsan zaman damgası tutan 32 bitlik alanları ve int kolonları ara.
İşe yarayan referans değerler
- 0 = 1970-01-01 00:00:00 UTC, epoch'un kendisi.
- 1000000000 = 2001-09-09 01:46:40 UTC, ilk on haneli zaman damgası.
- 1700000000 = 2023-11-14 22:13:20 UTC.
- 2000000000 = 2033-05-18 03:33:20 UTC.
- 2147483647 = 2038-01-19 03:14:07 UTC, 32 bit sınırı.
- 86400 = bir gün, 604800 = bir hafta, 3600 = bir saat.