Generator Timestamp Unix

Cara kerja

1. Konversi tanggal ke timestamp: masukkan tanggal dan waktu dengan pemilih, lalu klik Hasilkan untuk mendapatkan timestamp Unix dalam detik dan milidetik.
2. Konversi timestamp ke tanggal: tempel timestamp Unix (detik atau milidetik) untuk mengubahnya kembali menjadi tanggal dan waktu yang dapat dibaca.
3. Dapatkan timestamp saat ini: klik «Sekarang» untuk mendapatkan timestamp Unix saat ini secara instan.

Mengapa menggunakan generator timestamp Unix?

Timestamp Unix adalah bahasa universal waktu dalam komputasi, sebuah bilangan bulat tunggal yang mewakili detik yang berlalu sejak 1 Januari 1970 (UTC). Mereka menggerakkan basis data, API, log, token autentikasi, dan penjadwalan acara. Mengonversi secara manual antara timestamp dan tanggal yang dapat dibaca melibatkan perhitungan zona waktu yang mudah salah. Alat ini menangani konversi dengan benar di kedua arah, menghemat waktu dan menghindari bug zona waktu.

Fitur

• Konversi dua arah: tanggal/waktu → timestamp Unix dan timestamp Unix → tanggal/waktu.
• Detik dan milidetik: mendukung waktu Unix dalam detik (10 digit) maupun milidetik (13 digit).
• Penanganan zona waktu: menampilkan waktu di zona lokal Anda dan UTC untuk perbandingan tanpa ambiguitas.
• Tombol waktu sekarang: dapatkan timestamp saat ini secara instan.
• Tampilan relatif: menunjukkan berapa lama yang lalu atau dalam berapa lama (mis. «3 hari yang lalu»).

Pertanyaan yang sering diajukan

Apa itu timestamp Unix?

Timestamp Unix adalah jumlah detik yang berlalu sejak Unix epoch, tengah malam UTC pada 1 Januari 1970. Ini adalah representasi suatu saat yang independen dari zona waktu, menjadikannya format pilihan untuk menyimpan dan membandingkan saat dalam basis data dan API.

Mengapa JavaScript menggunakan milidetik?

Date.now() dan new Date().getTime() di JavaScript mengembalikan milidetik sejak epoch (angka 13 digit), sedangkan alat Unix dan sebagian besar basis data menggunakan detik (10 digit). Periksa apakah timestamp Anda memiliki 10 atau 13 digit untuk mengetahui format mana yang Anda miliki.

Bagaimana mengonversi timestamp ke waktu lokal?

Tempel timestamp; alat secara otomatis mengonversinya ke zona lokal peramban Anda. Tampilan menunjukkan baik waktu lokal maupun UTC untuk bekerja antar zona dengan percaya diri.

Dari mana asal waktu Unix

Waktu Unix didefinisikan oleh Ken Thompson dan Dennis Ritchie dalam Unix First Edition (November 1971). Awalnya kernel menghitung 1/60 detik sejak 1971-01-01 dalam bidang 32-bit, yang meluap setelah 2 tahun 9 bulan. Pada Unix Sixth Edition (1975) penghitungan diubah menjadi detik sejak 1970-01-01 00:00:00 UTC, epoch yang masih digunakan setiap sistem mirip Unix hingga hari ini. Pilihan tersebut sewenang-wenang, para insinyur membutuhkan tanggal bulat yang dekat dengan era tempat mereka bekerja. POSIX.1 (1988) mengkodifikasi definisi tersebut sebagai standar resmi, dan POSIX.1-2017 (IEEE Std 1003.1-2017), versi saat ini, masih mendefinisikan time_t sebagai jumlah detik sejak epoch, dengan peringatan bahwa waktu POSIX berpura-pura detik kabisat tidak ada. ISO 8601 (1988, saat ini 2019) menstandarisasi format yang dapat dibaca manusia 2026-05-13T14:30:00Z, dan RFC 3339 (Juli 2002) menyempitkannya menjadi profil tanggal-waktu internet yang tidak ambigu. Date.now() dari JavaScript mengembalikan milidetik sejak epoch karena spec ditulis pada 1995 ketika presisi sub-detik sudah dalam permintaan; sebagian besar database dan utilitas Unix masih menggunakan detik utuh.

Masalah Tahun 2038 (dan mengapa itu penting sekarang)

time_t 32-bit bertanda dapat merepresentasikan paling banyak 2.147.483.647 detik, yang tiba pada 03:14:07 UTC Selasa, 19 Januari 2038. Satu detik kemudian, penghitung membungkus ke −2.147.483.648, yang sebagian besar perangkat lunak ditafsirkan sebagai 13 Desember 1901. Ini adalah kelas bug yang sama dengan Y2K tetapi disebabkan oleh lebar integer, bukan format tanggal. Perbaikannya adalah menggunakan time_t 64-bit (yang mendorong wraparound ke sekitar tahun 292 miliar). Sebagian besar sistem Linux 64-bit sudah menggunakan time_t 64-bit secara default; Linux 5.6 (Maret 2020) membuat time_t 64-bit tersedia juga pada arsitektur 32-bit. Risiko yang tersisa hidup di sistem tertanam, format file biner lama, dan protokol jaringan 32-bit. Network Time Protocol (NTP) sudah membungkus pada 2036 karena menggunakan hitungan 32-bit tak bertanda sejak 1900, NTPv4 menambahkan nomor era untuk memperpanjangnya. Jika Anda mengirimkan perangkat lunak yang menangani tanggal, audit stack Anda sebelum 2038, terutama kolom SQL yang diketik sebagai INT(11) atau kode C lama dengan bidang waktu long.

Format timestamp yang akan Anda temui

• Detik Unix (10 digit). 1747143000. time_t POSIX klasik. Digunakan oleh PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), TTL Redis, klaim iat/exp JWT (sesuai RFC 7519), git log, dan sebagian besar utilitas Unix. Akan menjadi 11 digit setelah November 2286.
• Milidetik Unix (13 digit). 1747143000000. Date.now() JavaScript, System.currentTimeMillis() Java, Kafka, Elasticsearch, dan sebagian besar pipeline logging modern. Dikalikan 1000 hitungan detik.
• Mikrodetik Unix (16 digit) dan nanodetik (19 digit). 1747143000000000. Digunakan oleh time.time_ns() Python, time.Now().UnixNano() Go, revisi MVCC etcd, dan sistem perdagangan frekuensi tinggi di mana resolusi milidetik terlalu kasar.
• ISO 8601. 2026-05-13T14:30:00.000Z atau 2026-05-13T14:30:00+02:00. Dapat diurutkan sebagai string, tidak ambigu tentang zona waktu, diterima oleh hampir setiap API modern. Sufiks Z berarti «waktu Zulu», penanda NATO untuk UTC.
• RFC 3339. Profil yang lebih ketat dari ISO 8601 yang digunakan oleh JSON Schema, OpenAPI, dan sebagian besar API REST. Membutuhkan penanda zona waktu dan melarang beberapa fitur ISO 8601 seperti tanggal minggu dan tanggal ordinal.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. Format header email Date:. Masih ada di mana-mana karena SMTP berjalan di mana-mana.
• Tanggal serial Excel. Hari pecahan sejak 1900-01-01 (atau 1904 pada Excel Mac klasik). 2026-05-13 14:30 adalah sekitar 46150.6042. Excel terkenal memperlakukan 1900 sebagai tahun kabisat (bukan) untuk kompatibilitas Lotus 1-2-3.

Ketika alat ini mendapatkan tempatnya

• Debugging JWT. Token memiliki "exp": 1747143000 dan Anda perlu tahu apakah sudah kedaluwarsa. Tempel, lihat tanggal manusia.
• Forensik log. Sebuah baris berkata timestamp=1747143012345, Anda perlu mengkorelasikan dengan waktu jam dinding alat lain. 13 digit, jadi milidetik.
• Kueri basis data. Anda ingin menemukan baris setelah tanggal tertentu. WHERE created_at > 1747143000 membutuhkan nilai detik; salin dari alat.
• Fixture tes. Hardcoding «kemarin» dalam tes, Anda menghasilkan timestamp sekarang dan menempelnya ke spec.
• Cron / pekerjaan terjadwal. Verifikasi nilai detik di mana scheduler akan terpicu, terutama di seluruh transisi DST.
• Replay event. Offset Kafka dan indeks Elasticsearch sering menggunakan timestamp ms; konversi ke tanggal untuk memeriksa jendela replay tertentu.
• Invalidasi cache. Header Expires atau If-Modified-Since dalam format RFC 2822, hasilkan format wire yang benar untuk pengujian.

Kesalahan yang membuat tim kehilangan jam

• Mencampurkan detik dan milidetik. Meneruskan nilai 10 digit ke fungsi yang mengharapkan milidetik mengembalikan tanggal pada 1970, meleset dengan faktor 1000. Aturan 10-vs-13-digit adalah tes tercepat, nilai modern dalam detik adalah 10 digit hingga 2286, dalam milidetik 13 digit.
• Menyimpan waktu lokal. Selalu simpan UTC; konversi ke lokal pada waktu tampilan. Menyimpan "2026-05-13 14:30:00" tanpa zona waktu rusak begitu server, pengguna, atau lompatan DST mengubah offset lokal.
• Lupa transisi DST. 2:30 pagi terjadi dua kali selama mundur. Kode naif yang melakukan start + (24 * 3600) untuk berarti «besok» akan meleset satu jam dua kali setahun. Gunakan pustaka tanggal nyata (luxon, date-fns-tz, zoneinfo Python) yang mengetahui basis data IANA tz.
• Mengasumsikan waktu POSIX memperhitungkan detik kabisat. Tidak. 2016-12-31 23:59:60 ada di kehidupan nyata (detik kabisat ke-27) tetapi time_t POSIX melompat dari 23:59:59 ke 00:00:00 tanpa kesadaran akan detik tambahan. TAI (Waktu Atom Internasional) menghitung detik kabisat, waktu POSIX di-offset dari UTC dengan nol detik.
• Menyimpan time_t di kolom INT(4). Skema MySQL lama sering menggunakan INT yaitu 4 byte / 32-bit bertanda / membungkus pada 2038. Migrasi ke BIGINT atau TIMESTAMP. Tipe TIMESTAMP dari penyedia MySQL terhost juga 4 byte secara default, periksa dokumen.
• Mengurai ISO 8601 dengan regex. Implementasi setengah-setengah secara diam-diam membuang zona waktu. Gunakan parser platform: new Date(s) di JavaScript, datetime.fromisoformat(s) di Python ≥ 3.11, Instant.parse(s) di Java.
• Excel otomatis mengkonversi timestamp. Menempel 1747143012345 ke Excel tanpa awalan ' (apostrof literal) membuat Excel membacanya sebagai angka, kadang mengonversi ke notasi ilmiah. Format kolom sebagai Teks terlebih dahulu, atau tempel dengan awalan apostrof.

Pertanyaan yang lebih sering diajukan

Mengapa 1970-01-01 dipilih sebagai epoch?

Kenyamanan. Versi awal Unix di tahun 70-an ingin epoch yang tidak akan meluap dalam masa kerja yang wajar. 1970-01-01 adalah tanggal bulat yang dekat dengan era pengembangan, dan penghitung detik 32-bit dari sana mencapai 2038 dengan nyaman. Pilihan tersebut sekarang terukir di POSIX.1-2017 §4.16 dan merupakan salah satu kesepakatan lintas platform paling stabil dalam perangkat lunak. Tidak ada makna yang melekat pada tanggal, tidak ada peristiwa sejarah, tidak ada jangkar astronomis, hanya jangkar sewenang-wenang yang disetujui semua orang.

Apa perbedaan antara UTC, GMT, dan waktu Zulu?

Untuk tujuan perangkat lunak, mereka merujuk ke waktu jam dinding yang sama. UTC (Waktu Universal Terkoordinasi) adalah standar modern, didefinisikan oleh jam atom dan BIPM. GMT (Greenwich Mean Time) adalah standar astronomi Inggris yang lebih tua yang merupakan referensi dunia de facto sebelum penjagaan waktu atom. Waktu Zulu adalah penanda NATO/militer untuk UTC, ditulis sebagai sufiks Z dalam ISO 8601 (2026-05-13T14:30:00Z). UTC dan GMT dapat berbeda hingga 0,9 detik karena UTC diarahkan untuk tetap dekat dengan UT1 (waktu matahari rata-rata) melalui detik kabisat, tetapi tidak ada aplikasi yang tidak menggunakan UT1 secara langsung yang akan menyadari.

Mengapa 1970 kadang ditampilkan ketika saya mengharapkan sesuatu yang lain?

Dua penyebab umum. Pertama, timestamp dalam milidetik tetapi diteruskan ke fungsi yang mengharapkan detik, atau sebaliknya, memberi tanggal yang meleset dengan faktor 1000. Kedua, nilainya 0 atau NaN, keduanya yang sebagian besar pustaka tanggal render sebagai 1970-01-01T00:00:00Z. Periksa lebar integer mentah: 10 digit adalah detik, 13 milidetik, 16 mikrodetik, 19 nanodetik.

Apakah alat ini akan menangani timestamp negatif untuk tanggal sebelum 1970?

Ya. new Date(-86400000) mengembalikan 1969-12-31T00:00:00Z. Date JavaScript dapat merepresentasikan momen apa pun dari −271821-04-20 hingga +275760-09-13, yang kira-kira ±100 juta hari dari epoch. Di luar rentang itu, API mengembalikan Invalid Date. Untuk tanggal historis, sadari juga transisi Julian-Gregorian (1582 di negara-negara Katolik, 1752 di Inggris, sampai 1923 di Yunani) di mana tanggal kalender melompat 10 hingga 13 hari; pustaka tanggal bervariasi dalam cara mereka menangani ini.

Apakah data timestamp saya dikirim ke mana pun?

Tidak. Semua konversi berjalan di JavaScript di dalam browser Anda. Halaman tidak pernah POST nilai apa pun yang Anda masukkan. Buka tab Network di DevTools dan konversikan timestamp, Anda akan melihat nol permintaan keluar selama konversi. Aman untuk token dengan klaim timestamp, baris log internal, atau apa pun yang tidak akan Anda tempel ke layanan terhost.