Stempel Waktu Unix Cara Mengonversi dan Mengapa Sering Ditemukan

Timestamp Unix adalah jumlah detik yang telah berlalu sejak 1 Januari 1970, 00:00:00 UTC — juga dikenal sebagai epoch Unix. Tanggal tersebut tidak dipilih karena alasan teknis; ia hanya merupakan tahun saat ini ketika Unix sedang dirancang. Epoch selalu dalam UTC, yang berarti timestamp seperti ini 1712800000 mewakili momen yang sama di seluruh planet, terlepas dari zona waktu.

Timestamp Unix digunakan di mana-mana: header HTTP, token JWT, catatan database, file log, antrian pesan, dan respons API. Jika Anda sedang membangun atau memperbaiki sesuatu yang terkait dengan waktu, Anda akan sering menemukannya. The Pengubah Timestamp Unix IO Tools sangat berguna untuk pencarian cepat, tetapi Anda juga perlu tahu cara mengelolanya dalam kode.

Detik vs Milidetik: Kesalahan yang Menyebabkan Kebingungan

Kesalahan timestamp paling umum di produksi: membingungkan detik dan milidetik. Standar Unix menggunakan detik. JavaScript's Date.now() mengembalikan milidetik. Java juga demikian System.currentTimeMillis().

Timestamp dengan nilai 1712800000 adalah April 2024. Timestamp dengan nilai 1712800000000 (milidetik) adalah tahun 56.000-an. Jika perhitungan tanggal menghasilkan tanggal puluhan tahun ke depan atau menampilkan 1970-01-01, ini hampir selalu penyebabnya.

Aturan umum: jika timestamp memiliki 13 digit, maka ini milidetik. 10 digit, maka ini detik. Jika ragu, bagi dengan 1000 dan periksa apakah hasilnya masuk akal.

Mengonversi Timestamp Unix Berdasarkan Bahasa

Berikut pola yang akan Anda gunakan sehari-hari:

Bahasa Indonesia: JavaScript

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

Ular piton

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

SQL (MySQL / MariaDB)

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

Tabel Referensi Cepat

Kesalahan Zona Waktu

Timestamp Unix selalu dalam UTC. Selalu. Angka 1712800000 tidak memiliki zona waktu — ia hanya menghitung detik dari epoch. Zona waktu adalah masalah tampilan, bukan masalah penyimpanan.

Tempat pengembang terjebak:

• membedakan antara “datetime tidak sadar” (tidak memiliki informasi zona waktu) dan “datetime sadar” (dengan tzinfo). Datetime tidak sadar adalah penipuan — mereka terlihat valid tetapi tidak memiliki makna di antara sistem. datetime.fromtimestamp(ts) tanpa tz=timezone.utc — menggunakan zona waktu lokal server, secara diam-diam. Gunakan fromtimestamp(ts, tz=timezone.utc) alih-alih.
• MySQL’s FROM_UNIXTIME() — mengubah ke pengaturan zona waktu server MySQL (@@session.time_zone). Jika server Anda berada di UTC+8, hasilnya akan bergeser 8 jam.
• Menyimpan datetime di MySQL tanpa normalisasi UTC — jika server aplikasi dan server database berada di zona waktu yang berbeda, setiap insert atau baca adalah bug yang siap terjadi.

Polanya yang menghindari semua ini: simpan timestamp Unix di database, konversi ke format yang mudah dibaca saat tampilan di lapisan aplikasi, menggunakan zona waktu yang disukai pengguna.

Timestamps vs String ISO 8601: Apa yang Harus Disimpan

Keduanya adalah format penyimpanan yang valid. Perbandingannya:

• Timestamp Unix (integer): kompak, cepat untuk perbandingan dan perhitungan, tanpa ambiguitas zona waktu, bekerja di semua engine database. Kekurangannya: tidak bisa dibaca oleh manusia tanpa alat bantu.
• String ISO 8601 (misalnya, 2024-04-11T02:13:20Z): mudah dibaca oleh manusia di database, bersifat menjelaskan sendiri. Kekurangannya: lebih lambat untuk pencarian rentang, zona waktu bisa terlewat atau salah.

Untuk kebanyakan aplikasi: simpan timestamp sebagai bilangan bulat. Gunakan format ISO 8601 untuk API dan log ketika kebutuhan kejelasan manusia lebih tinggi. Jika harus menyimpan ISO 8601, selalu sertakan Z atau offset eksplisit — tanpa zona waktu saja adalah bencana dalam sistem terdistribusi. 2024-04-11 02:13:20 Masalah 2038

Integer tipe 32-bit signed dapat menyimpan nilai maksimum

, yang sesuai dengan 1 Januari 2038, 03:14:07 UTC. Sistem yang menyimpan timestamp Unix dalam tipe 32-bit 2147483647akan mengalami overflow pada saat itu — kembali ke tahun 1901 atau crash. int Apakah perlu khawatir? Jika Anda menulis kode baru, tidak — gunakan integer 64-bit. Jika Anda memelihara kode C lama, perangkat lunak terpasang, atau skema MySQL lama yang menggunakan

untuk timestamp, perlu diperiksa. Tipe MySQL INT(11) juga terpengaruh; TIMESTAMP tidak. Sistem modern yang menggunakan timestamp 64-bit aman hingga tahun 292 miliar. DATETIME Jika perlu mengonversi timestamp cepat tanpa menulis kode, maka

Pengubah Timestamp Unix di IO Tools mengelola detik dan milidetik, menampilkan waktu UTC dan lokal secara bersamaan, serta memungkinkan Anda menyalin tanggal untuk mendapatkan timestamp kembali. Timestamp Unix: Cara Mengonversi dan Mengapa Sering Ditemukan 2

Anda mungkin juga menyukai

Pembuatan Palet Warna: Membangun Palet Lengkap Dari Satu Hex:

Baca selengkapnya "

Diterbitkan pada 12 Mei 2026

Pemverifikasian Skema JSON: Mendeteksi Pelanggaran Kontrak API Sebelum Dikirim

Baca selengkapnya "

Diterbitkan pada 11 Mei 2026

Verifikasi Tanda Tangan PDF: Apa yang Perlu Diketahui Pengembang

Baca selengkapnya "

Diterbitkan pada 10 Mei 2026

Markdown vs HTML: Kapan Harus Menggunakan Masing-Masing untuk Dokumentasi, README, dan API

Baca selengkapnya "

Diterbitkan pada 9 Mei 2026