Konverter Timestamp
Ubah Unix timestamp menjadi tanggal yang mudah dibaca - dan sebaliknya. Anda mendapatkan detik, milidetik, ISO 8601, UTC, waktu lokal, nama hari, string RFC
Konversi antara timestamp Unix dan tanggal yang mudah dibaca, dua arah, baik dalam detik maupun milidetik. Tempel 1735689600 atau 2026-01-01T00:00:00Z dan lihat padanannya dalam UTC, di zona waktu lokal Anda, dan dalam format umum seperti ISO 8601 serta RFC 2822.
Hal ini sering muncul saat membaca log, men-debug API yang mengembalikan detik epoch, atau memastikan masa berlaku token sesuai dugaan Anda. Konversinya tepat dan berjalan lokal, serta alat ini memperingatkan Anda bila sebuah nilai tampak dalam milidetik, bukan detik.
Cara mengonversi timestamp Unix
Tempel timestamp atau tanggal
Baca nilai hasil konversi dalam UTC dan waktu lokal
Salin format yang Anda butuhkan
FAQ
Detik atau milidetik?
Sepuluh digit biasanya detik, tiga belas digit biasanya milidetik. Alat ini mendeteksi satuan yang paling mungkin dan memungkinkan Anda menggantinya jika hasilnya tampak salah.
Apa itu epoch Unix?
Jumlah detik sejak 1 Januari 1970 00:00:00 UTC, tanpa menghitung detik kabisat. Ini cara standar untuk menyimpan satu titik waktu.
Zona waktu mana yang dipakai?
Keduanya ditampilkan: UTC dan zona waktu lokal browser Anda, sehingga Anda bisa membandingkan apa yang dicatat server dengan apa yang Anda lihat di jam.
Apakah alat ini menangani tanggal sebelum 1970?
Ya, nilai negatif mewakili tanggal sebelum epoch, dan tanggal jauh di masa depan tetap berfungsi sampai batas rentang tanggal JavaScript.
Bisakah alat ini menghasilkan timestamp untuk sebuah tanggal?
Bisa, konversinya berjalan dua arah - masukkan tanggal dan dapatkan nilai epoch-nya.
Apakah ada yang diunggah?
Tidak, konversinya hanya aritmetika lokal.
Sekilas
| Masukan | teks |
|---|---|
| Beberapa file | Tidak |
| Dijalankan di | Di browser Anda - file tidak pernah diunggah |
| Bekerja offline | Ya — setelah halaman dimuat |
| Harga | Gratis, tanpa pendaftaran, tanpa tanda air |
Di mana konversi diam-diam rusak
Sebagian besar bug konversi bukan soal sintaksis, melainkan soal makna. Kolom kode pos pada CSV kehilangan angka nol di depannya begitu spreadsheet menduga kolom itu berisi angka; ID yang panjang melampaui presisi floating-point; tanggal berubah makna tergantung apakah formatnya tanggal-dulu atau bulan-dulu. Kunci JSON tidak berurutan, sedangkan array berurutan, dan alat yang mengurutkan kunci tidak mengubah apa pun sementara alat yang mengurutkan array mengubah datanya. Unicode adalah jebakan lain: teks bisa datang sebagai UTF-8, UTF-16, atau dengan BOM, dan dekoder yang salah menebak mengubah karakter beraksen menjadi mojibake. Sebelum memercayai konversi apa pun, periksa sekilas baris pertama dan terakhir, setiap bidang yang memiliki angka nol di depan, dan setiap bidang yang memuat tanda kutip, koma, atau baris baru.
Memilih format data
JSON adalah pilihan default untuk apa pun yang dikembalikan sebuah API atau dibaca sebuah program: format ini secara alami menangani struktur bersarang, angka, boolean, dan null, dan setiap bahasa bisa mengurainya. CSV lebih kecil dan langsung terbuka di spreadsheet, tetapi tidak punya cara untuk menyatakan penyarangan dan tidak punya standar bersama untuk pemisah, tanda kutip, atau set karakternya - dan di situlah konversi biasanya salah. XML lebih bertele-tele, tetapi membawa atribut, konten campuran, dan skema, sehingga masih mendominasi format dokumen dan integrasi warisan. YAML paling mudah dibaca untuk konfigurasi, tetapi peka terhadap spasi dan punya pemaksaan tipe yang mengejutkan ("no" menjadi false, versi seperti 1.10 menjadi 1.1). Pilih format yang disukai alat yang akan memakainya, bukan format yang terlihat paling bagus.