Konverter Timestamp Unix Gratis

Apa Itu Timestamp Unix?

Timestamp Unix (juga disebut waktu epoch atau waktu POSIX) adalah jumlah detik yang telah berlalu sejak 1 Januari 1970, 00:00:00 UTC. Ini adalah cara sederhana yang tidak bergantung pada zona waktu untuk merepresentasikan suatu titik waktu dan banyak digunakan dalam pemrograman, database, API, dan log server.

Sebagai contoh, timestamp 1700000000 merepresentasikan 14 November 2023 pukul 22:13:20 UTC. JavaScript menggunakan timestamp dalam milidetik (kalikan dengan 1000), sedangkan sebagian besar bahasa dan API lain menggunakan detik.

Pertanyaan yang Sering Diajukan

Format tanggal apa saja yang dapat saya masukkan?

Anda dapat memasukkan tanggal dalam sebagian besar format standar: ISO 8601 (2025-12-31T23:59:59Z), string tanggal umum (Dec 31, 2025 11:59 PM), atau format sederhana seperti 2025-12-31 23:59:59. Konverter menggunakan parser tanggal bawaan browser Anda.

Apakah otomatis mendeteksi detik vs milidetik?

Ya. Jika timestamp lebih besar dari 1 triliun, konverter memperlakukannya sebagai milidetik. Jika tidak, diperlakukan sebagai detik. Kedua format ditampilkan dalam tabel hasil.

Apa itu masalah Year 2038?

Sistem yang menyimpan timestamp Unix sebagai integer bertanda 32-bit akan mengalami overflow pada 19 Januari 2038 pukul 03:14:07 UTC. Sistem modern menggunakan integer 64-bit, yang dapat merepresentasikan tanggal miliaran tahun ke depan. Alat ini menggunakan tipe Number JavaScript, yang menangani timestamp jauh melampaui 2038.

Mengapa 1 Januari 1970?

Timestamp Unix adalah hitungan bilangan bulat detik yang telah berlalu sejak epoch Unix, 00:00:00 UTC pada hari Kamis, 1 Januari 1970. Ini adalah satu skalar yang secara unik memberi nama pada suatu momen waktu, tidak bergantung pada kalender dan zona waktu, angka yang sama memberi nama pada saat yang sama baik Anda di Tokyo maupun Toronto.

Pilihan 1970 agak sewenang-wenang, tetapi tidak acak. Edisi pertama UNIX Programmer's Manual (November 1971) mendefinisikan waktu sistem sebagai jumlah tick clock 60 Hz sejak 1 Januari 1971. Dengan integer tak bertanda 32-bit yang menghitung pada 60 Hz, sistem hanya akan bertahan sekitar 2,26 tahun sebelum overflow, masalah yang menjadi jelas dengan cepat. Ketika edisi kedua sedang dipersiapkan pada tahun 1972, tim Ken Thompson dan Dennis Ritchie beralih untuk menghitung detik sejak 1 Januari 1970: integer bertanda 32-bit yang menghitung detik akan bertahan sekitar 68 tahun, jauh melewati masa kerja para insinyur yang menulis kode, dan Tahun Baru terakhir sebelum proyek dimulai membuat aritmatika menjadi mudah. Tidak ada pemungutan suara komite dan tidak ada proses standardisasi gaya IANA. Pilihan tersebut menjadi kebiasaan karena Unix dikirim dengannya, dan begitu seratus juta mesin menghitung dari momen itu, tidak ada penggantian yang layak.

POSIX (1988) menyusun epoch 1970 sebagai "Seconds Since the Epoch" dari IEEE Std 1003.1. Hari ini, epoch yang sama mendasari time_t C/C++, time.time() Python, Time.now.to_i Ruby, JavaScript dan Java (dalam milidetik, lihat di bawah), timestamp file system Linux/macOS, header blok Bitcoin dan Ethereum, dan klaim iat/exp/nbf JWT. Beberapa sistem menggunakan epoch offset (FILETIME Windows menghitung tick 100 nanodetik sejak 1 Januari 1601, DateTime .NET menghitung tick sejak 1 Januari 0001), tetapi waktu Unix adalah lingua franca untuk segala sesuatu yang melintasi batas OS atau bahasa.

Detik vs milidetik, bug paling umum

POSIX mendefinisikan timestamp sebagai detik sejak epoch. Setiap pustaka C, setiap interpreter Python, setiap runtime Ruby/Go/Rust/Elixir mengembalikan detik. JavaScript adalah pengecualian yang terkenal, Date.now() dan new Date().getTime() mengembalikan milidetik. System.currentTimeMillis() Java mengikuti konvensi yang sama, dan beberapa sistem database yang lebih baru (tipe Date MongoDB BSON, misalnya) juga menyimpan milidetik.

Hasilnya adalah bug lintas-bahasa yang abadi: backend Go menulis 1700000000 (detik) ke dalam field JSON; klien Node.js meneruskannya ke new Date(1700000000), tetapi JavaScript mengharapkan milidetik, sehingga tanggal yang dihasilkan adalah 1970-01-20 bukannya akhir 2023. Perbaikannya adalah new Date(1700000000 * 1000). Sebaliknya, mengirim timestamp milidetik JS ke datetime.fromtimestamp() Python menghasilkan tahun ~55895. Stack Overflow memiliki puluhan varian pertanyaan "JavaScript Date menampilkan 1970", dan ketidakcocokan tersebut adalah penyebab utama di mayoritas besar.

Konverter ini menerapkan heuristik: jika input lebih besar dari 1.000.000.000.000, perlakukan sebagai milidetik; jika tidak, perlakukan sebagai detik. Ini berfungsi karena 1e12 detik akan menjadi tahun 33658 M (jauh melampaui input skala-detik dunia nyata), sedangkan 1e12 milidetik adalah 9 September 2001 UTC (dalam rentang modern). Timestamp mikrodetik dan nanodetik yang digunakan dalam beberapa sistem ilmiah dan API kernel Linux akan mendorong ambang batas lebih tinggi, untuk itu Anda harus menentukan presisi secara eksplisit.

Masalah Tahun 2038 ("Y2K38")

Integer bertanda 32-bit dapat menyimpan nilai dari −2.147.483.648 hingga +2.147.483.647. Diinterpretasikan sebagai detik sejak 1 Januari 1970 UTC, momen maksimum yang dapat direpresentasikan adalah 03:14:07 UTC pada hari Selasa, 19 Januari 2038. Satu detik kemudian, penghitung overflow dan membungkus ke nilai paling negatif, yang didekode sebagai 20:45:52 UTC pada hari Jumat, 13 Desember 1901. Setiap time_t selebar 32-bit, setiap kolom database yang menyimpan integer bertanda 4-byte untuk waktu, dan setiap sistem embedded yang firmware-nya ditulis sebelum sekitar 2010 berisiko.

Permukaan yang terpapar tidak nyaman: PLC industri dan kontroler SCADA dengan siklus hidup penyebaran 15-30 tahun yang dipasang hari ini; kolom TIMESTAMP MySQL yang lebih tua yang terdokumentasi mengalami saturasi pada batas 2038; file system ext3; format protokol biner (field RRSIG DNSSEC, NTPv3, beberapa fieldbus industri) yang mengemas timestamp 4-byte; smart TV dan infotainmen otomotif yang menjalankan kernel Linux 32-bit lebih lama yang dipasang secara diam-diam. Perbaikan mainstream adalah memperluas time_t menjadi 64-bit, yang memperpanjang maksimum hingga sekitar +292 miliar tahun, melewati kematian termal Matahari. Linux 5.6 (Maret 2020) menambahkan syscall waktu 64-bit ke semua arsitektur 32-bit melalui patchset y2038 Arnd Bergmann; glibc 2.34 (Agustus 2021) membuat time_t 64-bit opt-in melalui _TIME_BITS=64; Debian 13 "Trixie" (2025) adalah rilis pertama dengan arsip lengkap yang dikompilasi ulang. Apple sudah mendeprecate biner 32-bit di macOS 10.15 (2019) dan iOS 11 (2017), sehingga armada konsumen secara efektif kebal.

Permukaan risiko yang tersisa secara mayoritas adalah embedded dan data lama di disk: kernel 64-bit yang membaca kolom timestamp 32-bit dari database lama sama rusaknya dengan database itu sendiri. Migrasi adalah masalah format data per aplikasi, bukan hanya masalah kernel.

JavaScript Date, API paling terkutuk di bidang ini

Objek Date JavaScript disalin sepenuhnya dari Java 1.0 pada Mei 1995 selama sprint 10 hari yang Brendan Eich habiskan menulis LiveScript asli. Java sendiri mendeprecate sebagian besar metode java.util.Date di JDK 1.1 (1997), tetapi JavaScript mewarisinya dan tidak dapat merusak kompatibilitas web, jadi mereka tetap ada. Hasilnya adalah API di mana:

• Bulan diindeks dari 0 (new Date(2024, 0, 15) = 15 Januari) tetapi hari diindeks dari 1.
• getYear() mengembalikan "tahun minus 1900", getYear() untuk 2024 adalah 124. getFullYear() ditambahkan kemudian untuk mengembalikan 2024 secara langsung.
• Date.parse('2024-03-15') diparse sebagai tengah malam UTC; Date.parse('2024/03/15') adalah tengah malam lokal; Date.parse('March 15, 2024') didefinisikan oleh implementasi.
• Sebelum ECMAScript 5 (Desember 2009) parsing hampir sepenuhnya didefinisikan oleh implementasi, string input yang sama dapat menghasilkan nilai Date yang berbeda di IE, Firefox, Chrome dan Safari.

Temporal API (TC39 Stage 3 sejak Maret 2021) adalah pengganti modern, menyediakan Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime dan tipe Temporal.Duration yang sebenarnya. Dukungan browser sedang diluncurkan (Firefox Nightly, Safari 18 parsial, Chrome di balik flag pada 2024); polyfill berfungsi tetapi menambah ~25 KB. Moment.js dimasukkan ke mode pemeliharaan oleh pemeliharanya pada September 2020, untuk proyek baru di 2026 rekomendasinya adalah Temporal-pertama jika dukungan browser memungkinkan, Luxon atau date-fns lainnya, dan Moment.js tidak pernah.

Kapan Anda akan menggunakannya

• Debugging respons API. Sebagian besar API JSON mengembalikan timestamp sebagai integer Unix atau string ISO 8601, dan banyak yang mencampurnya. Menempelkan angka ke konverter puluhan kali sehari adalah use case bervolume tertinggi.
• Analisis file log. syslog, journald, AWS CloudWatch dan sebagian besar log aplikasi diberi timestamp dalam detik Unix. Insinyur menyalin timestamp dari baris log dan perlu mengetahui setara jam dinding.
• Inspeksi kolom tanggal database. Kueri psql atau mysql sekali pakai mengembalikan 1700000000; database memiliki fungsi seperti FROM_UNIXTIME() tetapi alat browser lebih cepat untuk pekerjaan ad-hoc.
• Inspeksi JWT. Mendekode token OAuth menampilkan "exp": 1738367200. Apakah token ini kedaluwarsa? Kapan kedaluwarsa? Konverter timestamp adalah jawaban tercepat.
• Timestamp blockchain. nTime blok Bitcoin adalah detik Unix (overflow di 2106, 4-byte tak bertanda). Timestamp blok Ethereum juga adalah detik Unix.
• Metadata file system OS. ls -l --time-style=+%s mencetak mtime Unix; stat -c '%Y' filename mengembalikan mtime sebagai integer. Rekonsiliasi timestamp forensik sering melibatkan dekoding manual.
• Sertifikat notBefore / notAfter dan header HTTP If-Modified-Since, semua timestamp yang kadang-kadang perlu didekode.

Catatan tentang detik kabisat

Sejak 1972, 27 detik kabisat telah dimasukkan ke UTC untuk menjaga waktu jam dinding selaras dengan rotasi Bumi yang melambat. Yang paling baru adalah 31 Desember 2016 23:59:60 UTC. Waktu Unix tidak mengenkode detik kabisat, POSIX secara eksplisit mengatakan timestamp Unix berpura-pura setiap hari memiliki tepat 86.400 detik. Sistem Linux yang lebih tua "mengulang" detik terakhir; Google dan AWS menggunakan "leap smear" yang menyebarkan detik ekstra ke jendela 24 jam. Bagaimanapun, waktu Unix tidak pernah membaca 23:59:60 dalam penyimpanan, dan mengurangi dua timestamp yang menjangkau detik kabisat menghasilkan jawaban satu detik lebih pendek dari waktu detik-SI sebenarnya yang berlalu. Untuk kode aplikasi ini tidak terlihat. Untuk perangkat lunak astronomi atau perdagangan keuangan, hal itu bisa penting. Pada November 2022, Konferensi Umum Bobot dan Ukuran ke-27 memilih untuk menghentikan penyisipan detik kabisat pada 2035, menggantinya dengan penyesuaian periodik yang jauh lebih besar.

Referensi cepat

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's nTime limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

Pertanyaan lain

Mengapa timestamp yang sama menampilkan waktu yang berbeda di mesin teman saya?

Karena angka yang mendasari adalah UTC, tetapi tampilan dikonversi ke waktu lokal. 1700000000 adalah 22:13:20 UTC, tetapi 17:13:20 di New York dan 06:13:20 hari berikutnya di Sydney. Angkanya sama; hanya rendering yang berbeda. Untuk mengesampingkan kebingungan zona waktu, minta kedua mesin untuk ditampilkan dalam UTC.

Apa perbedaan antara Y2K dan Y2K38?

Y2K (Tahun 2000) adalah masalah logika dalam kode aplikasi: banyak sistem menyimpan tahun sebagai dua digit ASCII, jadi "00" menjadi ambigu antara 1900 dan 2000. Setiap aplikasi harus diperiksa dan ditambal secara individual; total pengeluaran perbaikan di seluruh dunia diperkirakan sebesar $300-600 miliar. Y2K38 sebagian besar adalah masalah tipe data dalam pustaka tingkat rendah, kompilasi ulang pustaka C dan kernel terhadap time_t 64-bit memperbaiki sebagian besar permukaan untuk setiap aplikasi yang terhubung kepadanya. Kasus sulit yang tersisa adalah data yang dipertahankan di disk (database, metadata file, protokol biner) yang memerlukan alat migrasi data. Kebijaksanaan konvensional adalah bahwa 2038 akan menjadi peristiwa yang lebih kecil, kurang layak diberitakan dibanding 2000, lebih banyak kegagalan perangkat embedded terlokalisasi, lebih sedikit gangguan utama.

Mengapa new Date('2024-03-15') kadang-kadang menampilkan 14 Maret?

Karena string itu diparse sebagai tengah malam UTC per standar ES5, dan kemudian ditampilkan di zona waktu lokal Anda. Di zona UTC-8 seperti Pasifik AS, tengah malam UTC pada 15 Maret adalah 16:00 waktu lokal 14 Maret, jadi .getDate() mengembalikan 14. Perbaikan dalam kode modern adalah baik new Date('2024-03-15T12:00:00') (yang JavaScript parse sebagai siang lokal ketika Anda menghilangkan Z) atau, lebih baik, API Temporal.PlainDate.from() setelah dirilis.

Apakah ada yang dikirim ke server?

Tidak. Konversi adalah aritmatika JavaScript yang berjalan secara lokal di browser Anda. Tidak ada timestamp yang Anda masukkan meninggalkan halaman, berguna ketika nilai-nilai tersebut adalah ID pelanggan, baris log internal, atau data debug sesi yang lebih baik Anda tidak unggah ke mana pun. Halaman bekerja offline setelah dimuat.

Alat Terkait