Unix zaman damgası dönüştürücü
Bir Unix zaman damgasını herhangi bir saat diliminde okunabilir bir tarihe, tarihi de tekrar epoch'a dönüştürün.
Unix zaman damgası nedir
Bir Unix zaman damgası — epoch zamanı ya da POSIX zamanı da denir — 1 Ocak 1970, 00:00:00 UTC'den, yani Unix epoch olarak bilinen andan bu yana kaç saniye geçtiğini sayan tek bir sayıdır. Saat dilimi, takvim ve biçimlendirme olmayan tek bir tam sayı olduğu için, bir zaman anının saklanması, sıralanması, karşılaştırılması ya da bir ağ üzerinden gönderilmesi gerektiğinde bilgisayarların başvurduğu biçimdir. Veritabanınızdaki «created_at» sütununun, bir JWT'deki «iat» ve «exp» taleplerinin, bir dosyanın mtime değerinin ve okuyacağınız neredeyse her günlük dosyasındaki zaman damgalarının ardında duran şey budur.
Ödünleşim şu: çıplak bir sayı bir insan için hiçbir anlam ifade etmez. 1716197600 kusursuz bir andır, ama onun geçen Salı mı yoksa üç yıl önce mi olduğunu bir bakışta anlayamazsınız. Bu çeviriyi, her iki yönde de, bu araç yapar.
Saniye mi milisaniye mi — canını yakan belirsizlik
Özgün Unix kuralı tam saniyeleri sayar; bir kabukta date +%s'ten, PHP'nin time() işlevinden ve kırpıldığında Python'un time.time() değerinden aldığınız budur. JavaScript, Java ve daha birçoğu ise milisaniye sayar: Date.now() bin kat daha büyük bir sayı döndürür. İkisine de «zaman damgası» denir ve onları karıştırmak var olan en yaygın tarih hatalarından biridir.
Bu hata gürültülü değil, sessizdir. Bir milisaniye değerini saniye olarak okuyun, tarihiniz gelecekte on binlerce yıl ileri düşer; bir saniye değerini milisaniye olarak okuyun, her şey Ocak 1970'e çöker. Hiçbiri hata vermez — yalnızca, gerçek görünen yanlış bir tarih alırsınız.
Bu araç, sayının büyüklüğünden tahmin eder ve sonra ne tahmin ettiğini sonucun hemen yanında size söyler. Bugünün epoch saniyeleri on basamaklı, bugünün epoch milisaniyeleri on üç basamaklıdır; bu yüzden tahmin neredeyse her zaman doğrudur — ama bir hata raporuna yapıştırmak üzere olduğunuz bir değer için «neredeyse» yeterince iyi değildir; okumanın her zaman görünür ve değiştirmekten bir tık uzakta olmasının nedeni budur.
Saat dilimleri, UTC ve «yerel»in neden kaygan olduğu
Bir Unix zaman damgasının saat dilimi yoktur. Bir anı tanımlar ve aynı o an, aynı anda Londra'da 09:33, Kudüs'te 11:33 ve Tokyo'da 18:33'tür. Bir saat dilimi değerin parçası değildir; değere baktığınız bir mercektir.
Bu araç aynı anda birkaç merceği bu yüzden gösterir. UTC, her sunucunun ve günlüğün üzerinde anlaştığı nötr referanstır. Yerel saatiniz, kendi cihazınızın bildirdiği şeydir; hangi merceğin onu ürettiğini her zaman bilesiniz diye zon adıyla (Europe/Berlin gibi) gösterilir — algılama tarayıcınızda gerçekleşir; böylece Berlin'deki bir ziyaretçi Berlin saatini, Tokyo'daki bir ziyaretçi Tokyo saatini görür. Üçüncü satır, tam IANA saat dilimi veritabanından seçtiğiniz herhangi bir zondur; başka bir yerde yaşayan bir sunucudan bir günlük okurken istediğiniz satır budur.
- UTC — her sistemin üzerinde anlaştığı referans ve saklanacak ve günlüğe yazılacak doğru şey.
- Yerel — cihazınızın gördüğü aynı an; algılanan zonla etiketlenmiş.
- Seçtiğiniz bir zon — başka yerlerdeki makinelerden günlük ve izleri okumak için.
- ISO 8601 — değişim metin biçimi, örn. 2024-05-20T09:33:20.000Z.
- Göreli — «3 saat önce», bir şeyin ne kadar yakın zamanda olduğunu hızlıca anlamak için.
Kaymalar her zamanın yanında gösterilir (+03:00, -04:00), çünkü sabit değildir: çoğu zon yaz saati için bir saat kayar, dolayısıyla aynı zon yılın farklı zamanlarında farklı kaymalar üretebilir. Bir geçişe yakın bir tarih, tam da elle yapılan aritmetiğin yanıldığı yerdir.
Pratikte epoch zamanıyla çalışma
Her dilin ve kabuğun epoch değerlerini üretmenin ve okumanın kendi yolu vardır. Aklınızda tutmaya değer olanlar şunlardır:
date +%s # shell: current time in seconds date -d @1716197600 # shell (GNU): seconds back to a date Date.now() # JavaScript: current time in MILLIseconds new Date(1716197600 * 1000) # JavaScript: seconds to a Date time.time() # Python: seconds, as a float datetime.fromtimestamp(1716197600, tz=timezone.utc) SELECT EXTRACT(EPOCH FROM now()) -- PostgreSQL: seconds
Çoğu tarih derdinden kaçınan bir başparmak kuralı: anları UTC olarak saklayın ve iletin — ya bir epoch tam sayısı ya da bir ISO 8601 dizesi — ve yalnızca son anda, birine gerçekten gösterdiğinizde bir yerel zona çevirin. Erken biçimlendirmek, bir saat dilimi hatasının görünüm katmanınızda kalmak yerine verinize gömülmesinin yoludur.
Bilmeye değer bir şey daha: işaretli 32 bitlik bir saniye sayacı 19 Ocak 2038'de dolar, «2038 Yılı sorunu». Modern sistemler 64 bitlik değerler kullanır ve sorunsuzdur, ama eski gömülü cihazlar ve eski veritabanı sütunları, onunla hâlâ karşılaşabileceğiniz yerlerdir.
Sıkça sorulan sorular
- Sayımın saniye mi milisaniye mi olduğunu nasıl anlıyor?
- Büyüklüğünden: yaklaşık 1e11'in altındaki değerler saniye, daha büyükleri milisaniye olarak okunur. Bugün bu, on basamaklı saniyeleri on üç basamaklı milisaniyelerden temiz biçimde ayırır. Okuma sonucun yanında gösterilir ve tek tıkla değiştirebilirsiniz; böylece tahmin sizden asla gizlenmez.
- Hangi saat dilimi «yerel» sayılır?
- Kendi cihazınızın bildirdiği zon; tarayıcınızda algılanır ve şüpheye yer kalmasın diye adıyla gösterilir. Bu sizin zonunuzdur, sitenin değil — Berlin'deki bir ziyaretçi Berlin saatini, Tokyo'daki bir ziyaretçi Tokyo saatini görür.
- Bir tarihi tekrar zaman damgasına çevirebilir miyim?
- Evet. Aynı alan iki yönü de kabul eder: bir sayı yazın, bir tarih alırsınız; 2024-05-20 ya da 2024-05-20T09:33:20Z gibi bir tarih yazın, epoch değerini geri alırsınız. Değiştirilecek bir mod yoktur.
- 1970'ten önceki tarihleri işler mi?
- Evet. Epoch'tan önceki zaman damgaları yalnızca negatiftir — -86400, 31 Aralık 1969'dur — ve negatif değerler kabul edilir ve normal şekilde çevrilir.
- Zaman damgam neden beklediğimden farklı bir tarih gösteriyor?
- Neredeyse her zaman iki nedenden biri: saniye/milisaniye okuması varsaydığınız gibi değildir (etiketi kontrol edin ve değiştirin) ya da bir UTC değerini yerel saat beklentisiyle karşılaştırıyorsunuz. Araç iki satırı yan yana gösterir; böylece hangisi olduğunu görebilirsiniz.
- 2038 Yılı sorunu nedir?
- Epoch saniyelerini işaretli 32 bitlik bir tam sayıda saklayan sistemler 19 Ocak 2038'de taşar ve negatif bir sayıya döner, 1901'de tarihler verir. 64 bitlik değerler kullanan her şey — ki bu neredeyse tüm modern sistemlerdir — etkilenmez, ama eski gömülü sistemler ve eski veritabanı sütunları hâlâ risk altında olabilir.
- Girdiğim zaman damgası herhangi bir yere gönderiliyor mu?
- Hayır. Ayrıştırma, çevirme ve biçimlendirme tümüyle tarayıcınızda platformun kendi tarih ve saat dilimi desteğiyle çalışır. Yazdığınız hiçbir şey cihazınızdan asla çıkmaz.