Zaman Damgası Dönüştürücü
Bir Unix zaman damgasını okunabilir bir tarihe dönüştürün - ve geri. Saniye, milisaniye, ISO 8601, UTC, yerel saat, haftanın günü, bir RFC 2822 dizesi ve "3
Unix zaman damgaları ile okunabilir tarihler arasında iki yönde de, hem saniye hem milisaniye cinsinden dönüştürün. 1735689600 veya 2026-01-01T00:00:00Z değerini yapıştırın ve UTC'deki, yerel saat diliminizdeki ve ISO 8601 ile RFC 2822 gibi yaygın biçimlerdeki karşılığını görün.
Günlükleri okurken, epoch saniyesi döndüren bir API'de hata ayıklarken veya bir token'ın son kullanma tarihinin düşündüğünüz gibi olduğunu kontrol ederken bu sürekli karşımıza çıkar. Dönüşüm tamdır ve yerel olarak çalışır; ayrıca bir değer saniye değil de milisaniye gibi görünüyorsa sizi uyarır.
Unix zaman damgası nasıl dönüştürülür
Bir zaman damgası veya tarih yapıştırın
Dönüştürülen değerleri UTC ve yerel saatte okuyun
İhtiyacınız olan biçimi kopyalayın
SSS
Saniye mi milisaniye mi?
On hane genellikle saniyedir, on üç hane genellikle milisaniyedir. Araç olası birimi algılar ve sonuç yanlış görünüyorsa birimi değiştirmenize izin verir.
Unix epoch nedir?
1 Ocak 1970 00:00:00 UTC'den bu yana geçen saniye sayısıdır; artık saniyeler sayılmaz. Bir zaman noktasını saklamanın standart yoludur.
Hangi saat dilimi kullanılıyor?
İkisi de gösterilir: UTC ve tarayıcınızın yerel saat dilimi; böylece sunucunun günlüğe yazdığıyla saatinizde gördüğünüzü karşılaştırabilirsiniz.
1970 öncesi tarihleri işliyor mu?
Evet, negatif değerler epoch öncesi tarihleri temsil eder ve çok uzak gelecekteki tarihler JavaScript tarih aralığının sınırlarına kadar çalışır.
Bir tarih için zaman damgası üretebilir mi?
Evet, dönüşüm iki yönde de çalışır - bir tarih girin ve epoch değerini alın.
Bir şey yükleniyor mu?
Hayır, dönüşüm yerel bir aritmetik işlemdir.
Bir bakışta
| Girdi | metin |
|---|---|
| Birden fazla dosya | Hayır |
| Nerede çalışır | Tarayıcınızda - dosyalar hiçbir zaman yüklenmez |
| Çevrimdışı çalışır | Evet — sayfa yüklendikten sonra |
| Fiyat | Ücretsiz, kayıt yok, filigran yok |
Dönüştürmelerin sessizce bozulduğu yerler
Dönüştürme hatalarının çoğu söz dizimiyle ilgili değil, anlamla ilgilidir. Bir posta kodu sütunu, elektronik tablo onu bir sayı sandığı anda baştaki sıfırlarını kaybeder; uzun bir kimlik kayan nokta hassasiyetini aşar; tarihler gün-önce mi ay-önce mi olduğuna göre anlam değiştirir. JSON anahtarları sırasızdır ama diziler sıralıdır; anahtarları sıralayan bir araç hiçbir şeyi değiştirmez, dizileri sıralayan bir araç ise veriyi değiştirir. Unicode başka bir tuzaktır: metin UTF-8, UTF-16 ya da bir bayt sırası işaretiyle gelebilir ve yanlış tahmin eden bir çözücü aksanlı karakterleri bozuk metne çevirir. Herhangi bir dönüştürmeye güvenmeden önce ilk ve son satırı, başta sıfır bulunan her alanı ve tırnak, virgül ya da satır sonu içeren her alanı kontrol edin.
Bir veri biçimi seçmek
JSON, bir API'nin döndürdüğü ya da bir programın okuduğu her şey için varsayılandır: iç içe yapıları, sayıları, boolean değerleri ve null'ı doğal biçimde işler ve her dil onu ayrıştırır. CSV daha küçüktür ve doğrudan bir elektronik tabloda açılır, ancak iç içe yapıyı ifade etmenin hiçbir yolu yoktur ve ayırıcı, tırnaklama ya da karakter kümesi için ortak bir standardı yoktur - dönüştürmelerin tam olarak bozulduğu yer burasıdır. XML ayrıntılıdır ama öznitelikleri, karışık içeriği ve şemaları taşır; bu yüzden belge biçimlerine ve eski entegrasyonlara hâlâ hâkimdir. YAML yapılandırma için en okunabilir olanıdır ama boşluklara duyarlıdır ve şaşırtıcı tür dönüşümleri vardır ("no" değerinin false olması, 1.10 gibi bir sürümün 1.1'e dönüşmesi). En hoş görüneni değil, tüketen aracın tercih ettiği biçimi seçin.