Konverter Unix Timestamp

Konversi Unix timestamp ke tanggal — dan sebaliknya — secara instan

Konverter Unix timestamp ini mengubah waktu epoch apa pun menjadi tanggal yang bisa dibaca manusia dan mengonversi tanggal apa pun kembali menjadi timestamp, sepenuhnya di browser Anda. Ticker langsung menampilkan waktu Unix saat ini yang berjalan dalam detik dan milidetik sehingga Anda selalu punya epoch segar untuk disalin. Tanpa pendaftaran, tanpa server, tidak ada yang diunggah.

Tempel angka apa pun dan alat ini secara otomatis mendeteksi apakah itu dalam detik (10 digit), milidetik (13 digit), atau mikrodetik (16–17 digit), lalu menampilkan hasilnya dalam waktu lokal Anda, UTC, ISO 8601, RFC 2822, dan format relatif yang ramah seperti '3 jam yang lalu'. Setiap output memiliki tombol salin sekali klik.

Timestamp → tanggal dan tanggal → timestamp

Panel Timestamp → tanggal menerima Unix timestamp positif atau negatif apa pun. Timestamp negatif mewakili tanggal sebelum 1970 — Unix timestamp −86.400 adalah 31 Desember 1969 00:00:00 UTC. Timpa unit yang terdeteksi otomatis untuk memaksa detik, milidetik, atau mikrodetik saat Anda tahu persis format apa yang Anda miliki.

Panel Tanggal → timestamp bekerja dengan cara sebaliknya: pilih tanggal dan waktu apa pun, pilih zona waktu Anda dari daftar zona waktu IANA lengkap, dan dapatkan Unix detik dan milidetik yang tepat untuk momen tersebut. Secara default menunjukkan waktu saat ini sehingga Anda bisa langsung melihat epoch hari ini.

Tag timestamp Discord — hasilkan ketujuh format

Discord merender Unix timestamp dalam pesan chat menggunakan tag seperti <t:1700000000:F>, yang klien Discord tampilkan secara otomatis dalam zona waktu lokal setiap pembaca. Ada tujuh kode format: t (waktu singkat), T (waktu panjang), d (tanggal singkat), D (tanggal panjang), f (tanggal dan waktu singkat — default), F (tanggal dan waktu panjang dengan hari dalam seminggu), dan R (relatif — 'dalam 3 jam', '2 tahun yang lalu').

Sebagian besar generator timestamp Discord hanya menghasilkan satu atau dua dari tujuh format — hammertime.cyou menghasilkan ketujuhnya tetapi memerlukan kunjungan situs terpisah dan tidak memiliki deteksi otomatis epoch. Alat ini menghasilkan ketujuhnya sekaligus, dengan pratinjau bagaimana masing-masing akan dirender dalam waktu lokal Anda, dan tombol salin untuk setiap tag. Berfungsi di iPhone, Android, dan desktop.

Perbandingan dengan EpochConverter.com dan unixtimestamp.com

EpochConverter.com adalah pemimpin kategori — ia menangani timestamp detik dan milidetik dengan baik dan cepat. Tetapi tidak mendeteksi skala secara otomatis (Anda menentukan detik vs md), tidak memiliki generator tag Discord, dan tidak menunjukkan dukungan mikrodetik. Unixtimestamp.com lebih sederhana lagi — hanya detik, tanpa output Discord, tanpa waktu relatif.

Alat ini mendeteksi ketiga skala secara otomatis berdasarkan jumlah digit, menghasilkan ketujuh tag format Discord, menampilkan waktu relatif, dan berjalan sepenuhnya di browser Anda tanpa akun. Bagi pengembang yang perlu men-debug file log, respons API, dan bot Discord dalam satu tab, kombinasi itu tidak tersedia di kedua situs tersebut.

Deteksi otomatis detik, milidetik, dan mikrodetik

Sumber kebingungan paling umum dengan Unix timestamp adalah skala. Timestamp detik seperti 1700000000 memiliki 10 digit dan mewakili tanggal di November 2023. Momen yang sama sebagai timestamp milidetik adalah 1700000000000 — 13 digit, seribu kali lebih besar. Date.now() JavaScript mengembalikan milidetik; perintah shell Unix date +%s mengembalikan detik. API dan database sangat bervariasi.

Timestamp 16 dan 17 digit adalah mikrodetik — digunakan dalam data sensor presisi tinggi, pelacakan terdistribusi, dan beberapa database NoSQL. Konverter ini mengidentifikasi skala berdasarkan jumlah digit dan mengonversi dengan benar setiap saat. Anda juga bisa menimpa deteksi dan memaksa unit tertentu.

Konversi epoch di Python, JavaScript, dan SQL

Di Python, konversi dengan datetime.fromtimestamp(ts, tz=timezone.utc) untuk UTC, atau hilangkan tz untuk mendapatkan hasil dalam zona waktu lokal server (yang menyebabkan bug di mesin berbeda). Timestamp detik saat ini adalah int(time.time()); milidetik adalah int(time.time() * 1000). Di JavaScript, new Date(ts * 1000) mengubah timestamp detik menjadi objek Date; Date.now() memberikan epoch milidetik saat ini.

Di MySQL, UNIX_TIMESTAMP() mengembalikan epoch saat ini dalam detik dan FROM_UNIXTIME(ts) mengonversi kembali ke datetime. Di PostgreSQL, EXTRACT(EPOCH FROM timestamptz) memberikan epoch detik dan TO_TIMESTAMP(ts) mengonversi ke arah lain. Alat ini menangani kasus khusus yang sering menjebak pengembang: masalah Tahun 2038, timestamp negatif sebelum 1970, dan ketiga skala presisi.

Privat, mampu offline, dan instan

Setiap konversi berjalan secara lokal di browser Anda — tidak ada server, tidak ada yang diunggah, dan tidak ada permintaan jaringan yang dibuat. Halaman ini berfungsi setelah dimuat bahkan saat Anda offline. Simpan sebagai bookmark untuk akses cepat lain kali Anda menemukan bilangan bulat yang mencurigakan di file log, respons API, catatan database, atau payload JWT dan perlu tahu tanggal dan waktu apa yang diwakilinya.

Mengapa 1 Januari 1970? Asal-usul epoch Unix

Pemilihan 1 Januari 1970 00:00:00 UTC sebagai epoch Unix bersifat pragmatis, bukan seremonial. Insinyur di Bell Labs membutuhkan titik referensi tetap saat membangun sistem Unix pertama sekitar 1969–1971. Mereka ingin angka bulat yang dekat dengan masa kini sehingga timestamp yang khas akan menjadi bilangan bulat positif kecil yang cocok dengan nyaman dalam kata 32-bit yang tersedia saat itu. 1970 adalah tahun bulat terdekat dengan saat pekerjaan itu dilakukan, dan itu bertahan secara permanen.

Satu hal halus yang penting adalah bahwa waktu POSIX mengabaikan detik kabisat. UTC sesekali menyisipkan detik kabisat untuk menjaga waktu atom tetap selaras dengan rotasi Bumi — misalnya, detik kabisat ditambahkan pada akhir 2016. POSIX memperlakukan setiap hari sebagai tepat 86.400 detik terlepas dari itu, sehingga Unix timestamp 1483228800 sesuai dengan 2017-01-01 00:00:00 UTC apakah detik kabisat terjadi pada tengah malam sebelumnya atau tidak. Ini berarti waktu Unix bukan hitungan linear sempurna dari detik SI, tetapi konsisten dan tidak ambigu untuk konversi tanggal-waktu yang menjadi perhatian hampir setiap aplikasi.

UTC (Coordinated Universal Time) dan GMT (Greenwich Mean Time) sering digunakan secara bergantian dalam dokumentasi, tetapi keduanya secara teknis berbeda. GMT adalah standar astronomi berdasarkan rotasi Bumi; UTC dipelihara oleh jam atom dan dijaga dalam 0,9 detik dari GMT dengan penyisipan detik kabisat secara berkala. Untuk semua pekerjaan timestamp praktis, perbedaan itu tidak relevan — keduanya berbeda paling banyak sebagian kecil detik — tetapi UTC adalah istilah yang benar untuk referensi yang digunakan dalam waktu Unix.

Masalah Tahun 2038: saat timestamp 32-bit meluap

Bilangan bulat bertanda 32-bit bisa menampung nilai dari −2.147.483.648 hingga 2.147.483.647. Ketika Unix timestamp disimpan dalam tipe itu — seperti pada kernel Linux awal dan banyak program C yang ditulis sebelum komputasi 64-bit menjadi universal — penghitung mencapai batasnya pada 03:14:07 UTC pada 19 Januari 2038. Satu detik kemudian nilainya melingkar ke bilangan bulat negatif 32-bit terbesar, yang ditafsirkan sistem sebagai tanggal di Desember 1901. Ini adalah masalah Tahun 2038, kadang disebut Y2K38.

Risiko praktis terkonsentrasi pada basis kode berumur panjang yang tidak pernah dimodernisasi: sistem tertanam di pengontrol industri dan perangkat medis, firmware di peralatan jaringan, skema database lama yang menyimpan timestamp sebagai kolom INT alih-alih tipe datetime yang tepat, dan pustaka C lawas. Perbaikannya sederhana secara prinsip — migrasi ke bilangan bulat 64-bit, yang mendorong tanggal meluap hingga sekitar 292 miliar tahun ke depan — tetapi menemukan dan memperbarui setiap sistem yang terpengaruh membutuhkan waktu dan pengujian. Linux memigrasikan time_t-nya ke 64-bit pada platform ARM 32-bit di kernel 5.6 (2020), jauh sebelum tenggat waktu.

Y2K38 berbeda dari masalah Y2K asli dengan cara yang penting. Y2K adalah masalah representasi data — banyak sistem hanya menyimpan dua digit untuk tahun, sehingga 2000 terlihat seperti 1900 — dan memerlukan pembaruan perangkat lunak terkoordinasi di hampir setiap organisasi secara bersamaan. Y2K38 adalah peluapan tipe data di sistem tertentu yang kebetulan menggunakan timestamp 32-bit, dan perangkat lunak modern yang ditulis dalam 15 tahun terakhir hampir pasti tidak terpengaruh. Risikonya nyata tetapi terbatas cakupannya, menjadikannya lebih sedikit krisis global dan lebih ke masalah audit tertarget bagi tim yang memelihara infrastruktur lawas.

ISO 8601 dan alasan untuk string tanggal yang terstandarisasi

ISO 8601 adalah standar internasional yang mendefinisikan cara menulis tanggal dan waktu sebagai string. Bentuk kanoniknya adalah YYYY-MM-DDTHH:MM:SS±HH:MM — tahun, bulan, dan hari dipisahkan dengan tanda hubung; karakter T literal memisahkan tanggal dari waktu; jam, menit, dan detik dipisahkan dengan titik dua; dan offset zona waktu seperti +05:30 atau akhiran Z untuk menunjukkan UTC. Date.toISOString() JavaScript selalu mengembalikan format ini dengan milidetik dan akhiran Z: 2023-11-14T22:13:20.000Z.

Sifat paling berguna dari ISO 8601 adalah bahwa ia dapat diurutkan secara leksikografis: mengurutkan string secara alfabetis menghasilkan urutan kronologis yang benar. Sifat itu membuat ISO 8601 aman digunakan sebagai kunci dalam sistem berkas, penyimpanan objek, dan database di mana Anda ingin pengurutan kronologis tanpa penguraian. Standar ini juga mendefinisikan bentuk ringkas (20231114 untuk tanggal saja), notasi minggu (2024-W23-3 berarti hari ketiga dari minggu ke-23 tahun 2024), dan notasi durasi (P1Y2M3DT4H). RFC 2822, digunakan dalam header email, mengambil pendekatan berbeda: Mon, 03 Jun 2024 12:34:56 +0000 — bisa dibaca manusia tetapi tidak bisa diurutkan sebagai string dan sulit diurai.

Format khusus wilayah seperti MM/DD/YYYY (umum di Amerika Serikat) dan DD/MM/YYYY (umum di Eropa) pada dasarnya ambigu: string 04/05/2024 berarti 5 April dalam satu konvensi dan 4 Mei dalam yang lain. Format ini baik untuk ditampilkan kepada pengguna akhir dalam lokal yang diketahui, tetapi tidak boleh digunakan dalam penyimpanan data, file log, payload API, atau konteks apa pun di mana string akan dibaca oleh kode atau oleh orang di wilayah berbeda. ISO 8601 menghilangkan ambiguitas sepenuhnya.

Zona waktu di database: selalu simpan UTC, konversi saat ditampilkan

Praktik terbaik universal untuk penyimpanan timestamp adalah selalu menyimpan dalam UTC dan mengonversi ke waktu lokal hanya saat merender untuk pengguna. Alasannya menjadi jelas pada batas DST yang dikenal sebagai 'fall back': ketika jam di zona waktu Timur AS mundur dari pukul 2:00 pagi ke 1:00 pagi, waktu lokal 1:30 pagi terjadi dua kali dalam malam yang sama. Sistem yang menyimpan waktu lokal tidak memiliki cara untuk membedakan 1:30 pagi pertama dari yang kedua tanpa konteks tambahan. UTC tidak memiliki pergeseran waktu musim panas, sehingga kedua momen tersebut memiliki nilai UTC yang sepenuhnya berbeda dan selalu tidak ambigu.

PostgreSQL membuat perbedaan itu eksplisit dengan dua tipe kolom terpisah. TIMESTAMP WITH TIME ZONE (juga ditulis TIMESTAMPTZ) selalu mengonversi input ke UTC saat penyimpanan dan menerapkan kembali zona waktu sesi saat pengambilan — terlepas dari offset apa yang Anda berikan saat menyisipkan baris. TIMESTAMP WITHOUT TIME ZONE menyimpan persis string yang Anda berikan, tanpa kesadaran zona waktu sama sekali. Jika Anda menyisipkan 2024-03-10 02:30:00 ke dalam kolom TIMESTAMP WITHOUT TIME ZONE, nilai literal itulah yang kembali, meskipun momen tertentu itu tidak ada di jam AS karena jatuh di dalam celah spring-forward DST. MySQL memiliki pemisahan yang sama: TIMESTAMP menormalkan ke UTC; DATETIME menyimpan nilai literal tanpa konversi.

Saat menyandikan informasi zona waktu dalam string ISO 8601, lebih baik gunakan nama zona waktu IANA (America/New_York, Europe/Berlin) daripada offset UTC tetap (-05:00). Offset tetap hanya benar pada momen tertentu; ia tidak bisa menangkap fakta bahwa America/New_York adalah -05:00 di musim dingin dan -04:00 di musim panas. Pustaka seperti Luxon, date-fns-tz, dan modul zoneinfo Python menggunakan basis data IANA untuk menyelesaikan offset yang benar untuk momen apa pun dalam waktu, secara otomatis memperhitungkan transisi DST, perubahan offset historis, dan pembaruan aturan di masa depan.