Konversi Unix Timestamp di SQL

Unix timestamp adalah jumlah detik sejak 1 Januari 1970 UTC, dan di SQL kamu konversi ke tanggal pakai to_timestamp di PostgreSQL atau FROM_UNIXTIME di MySQL.

Angka kayak 1704067200 sering muncul di kolom waktu hasil ekspor dari aplikasi, log event, atau API. Buat manusia, angka itu nggak ada artinya. Buat mesin, itu cara paling ringkas nyimpen waktu.

Di artikel ini kamu bakal belajar konversi dua arah, beda detik dan milidetik, cara nangani timezone, dan contoh nyata dari log transaksi toko UMKM.

Apa itu Unix timestamp?

Unix timestamp adalah cara nyimpan waktu sebagai satu angka: jumlah detik yang udah berlalu sejak tengah malam 1 Januari 1970 dalam waktu UTC. Titik awal itu disebut epoch. Karena cuma satu angka, timestamp gampang disimpan, diurutkan, dan dibandingkan tanpa pusing format tanggal.

Banyak sistem nyimpan waktu begini biar konsisten lintas timezone. Satu angka yang sama artinya sama di server mana pun. Baca lebih lanjut soal Unix timestamp dan konsep epoch time kalau mau paham dasarnya.

Gimana cara konversi Unix timestamp ke tanggal di PostgreSQL?

Pakai fungsi to_timestamp dengan angka epoch-nya sebagai argumen. PostgreSQL balikin nilai bertipe timestamptz dalam UTC, yang bisa langsung kamu format atau geser ke timezone lokal. Fungsi ini nerima detik, bukan milidetik.

SELECT to_timestamp(1704067200);
-- hasil: 2024-01-01 00:00:00+00

Kalau kolomnya bertipe bigint bernama created_epoch, tinggal bungkus kolomnya:

SELECT id, to_timestamp(created_epoch) AS waktu
FROM transaksi;

Buat balik dari tanggal ke angka epoch, pakai EXTRACT dengan EPOCH. Hasilnya berupa angka desimal, jadi cast ke bigint kalau kamu mau angka bulat.

SELECT EXTRACT(EPOCH FROM TIMESTAMP '2024-01-01 00:00:00')::bigint;
-- hasil: 1704067200

Gimana cara konversi Unix timestamp di MySQL?

MySQL punya dua fungsi pasangan: FROM_UNIXTIME buat ngubah angka jadi tanggal, dan UNIX_TIMESTAMP buat ngubah tanggal jadi angka. Sama kayak PostgreSQL, input dan output default ngikutin detik, bukan milidetik.

SELECT FROM_UNIXTIME(1704067200);
-- hasil: 2024-01-01 07:00:00 (kalau timezone server WIB)

SELECT UNIX_TIMESTAMP('2024-01-01 00:00:00');
-- hasil: 1704067200

Bedanya, FROM_UNIXTIME ngikutin timezone yang diset di session MySQL. Jadi kalau server-nya WIB, hasilnya udah digeser 7 jam. Ini beda sama PostgreSQL to_timestamp yang selalu balikin UTC dulu.

Detik atau milidetik? Ini jebakan paling sering

Banyak aplikasi modern, terutama dari JavaScript, nyimpen timestamp dalam milidetik, bukan detik. Angkanya jadi 13 digit, bukan 10 digit. Kalau kamu langsung masukin ke to_timestamp tanpa penyesuaian, hasilnya lompat ribuan tahun ke depan.

Satuan	Contoh nilai	Jumlah digit
Detik	1704067200	10
Milidetik	1704067200000	13

Aturannya gampang: kalau angkanya 13 digit, bagi 1000 dulu.

SELECT to_timestamp(1704067200000 / 1000);

Cek cepat: timestamp detik buat tahun 2020-an itu di kisaran 1,6 sampai 1,8 miliar. Kalau angkamu jauh lebih besar, kemungkinan besar itu milidetik.

Cara nangani timezone waktu konversi

Unix timestamp selalu UTC. Kalau kamu di Indonesia dan mau nampilin waktu lokal, geser ke Asia/Jakarta pakai AT TIME ZONE di PostgreSQL.

SELECT to_timestamp(1704067200) AT TIME ZONE 'Asia/Jakarta';
-- hasil: 2024-01-01 07:00:00

Selisih 7 jam itu WIB. Kalau kamu lewatin langkah ini, laporan harian bisa salah tanggal buat transaksi yang kejadian menjelang tengah malam. Bahas lengkap soal ini ada di menangani timezone pada data waktu di SQL.

Contoh kasus: log transaksi toko_berkah

Aku pegang tabel log dari aplikasi kasir toko_berkah. Kolom waktunya bernama waktu_epoch, bertipe bigint, dan isinya angka epoch dalam detik. Ada 4.200 baris transaksi selama satu bulan.

Aku mau tau jam berapa toko paling ramai. Query-nya konversi epoch ke waktu WIB, ambil jamnya, terus hitung per jam.

SELECT
  EXTRACT(HOUR FROM to_timestamp(waktu_epoch) AT TIME ZONE 'Asia/Jakarta') AS jam,
  COUNT(*) AS jumlah
FROM log_transaksi
GROUP BY jam
ORDER BY jumlah DESC;

Hasilnya kelihatan: 31% transaksi (1.302 dari 4.200) numpuk di jam 17 sampai 19. Sore hari pas orang pulang kerja. Tanpa konversi timezone, angka ini bakal ketarik ke jam 10 sampai 12 karena masih UTC, dan kesimpulannya salah total.

Kesalahan umum konversi Unix timestamp

• Lupa cek detik vs milidetik. Angka 13 digit yang nggak dibagi 1000 ngasih tahun yang absurd.
• Ngira hasilnya udah lokal. to_timestamp balikin UTC. Kamu harus geser sendiri ke WIB.
• Nyimpen epoch di kolom INT biasa. INT 32-bit mentok di tahun 2038. Pakai bigint biar aman.
• Bandingin epoch sama tanggal langsung. Konversi salah satunya dulu biar tipe datanya cocok.

FAQ

Pertanyaan yang sering muncul soal Unix timestamp di SQL.

Kenapa hasil konversi Unix timestamp-ku jadi tahun yang aneh?

Kemungkinan besar angkamu dalam milidetik, bukan detik. Fungsi kayak to_timestamp dan FROM_UNIXTIME ngarepin detik. Kalau kamu masukin nilai 13 digit dalam milidetik tanpa dibagi 1000, hasilnya lompat ribuan tahun ke depan. Cek jumlah digitnya dulu. Timestamp detik buat tahun 2020-an itu 10 digit, sekitar 1,7 miliar. Kalau 13 digit, bagi 1000 sebelum dikonversi.

Apakah Unix timestamp menyimpan informasi timezone?

Nggak. Unix timestamp selalu dihitung dalam UTC dan nggak nyimpen timezone sama sekali. Itu justru keunggulannya, karena satu angka artinya sama di server mana pun. Kalau kamu butuh nampilin waktu lokal Indonesia, kamu harus geser sendiri ke Asia/Jakarta, misalnya pakai AT TIME ZONE di PostgreSQL. Tanpa itu, laporan harianmu bisa salah tanggal buat transaksi menjelang tengah malam.

Kenapa jangan simpan Unix timestamp di kolom INT biasa?

Kolom INT 32-bit cuma sanggup nampung nilai sampai sekitar 2,1 miliar, yang setara dengan tanggal 19 Januari 2038. Lewat dari itu, angkanya overflow dan waktunya jadi ngaco. Masalah ini terkenal dengan nama Year 2038 problem. Solusinya simpan epoch di kolom bigint yang jauh lebih besar kapasitasnya, jadi datamu aman sampai jauh ke depan.

Gimana cara bandingin dua Unix timestamp buat hitung selisih waktu?

Karena keduanya angka detik, kamu tinggal kurangin langsung. Selisihnya juga dalam detik. Bagi 60 buat dapat menit, bagi 3600 buat jam, atau bagi 86400 buat hari. Cara ini malah lebih gampang daripada ngurangin dua tanggal, karena hasilnya udah berupa angka bersih. Pastiin dua angkanya pakai satuan sama, sama-sama detik atau sama-sama milidetik.

Penutup

Konversi Unix timestamp intinya dua fungsi: to_timestamp dan EXTRACT EPOCH di PostgreSQL, atau FROM_UNIXTIME dan UNIX_TIMESTAMP di MySQL. Dua hal yang wajib kamu cek tiap kali: apakah angkanya detik atau milidetik, dan apakah hasilnya perlu digeser ke WIB.

Sekali kamu terbiasa, kolom angka gede itu nggak bikin bingung lagi. Mau latihan query tanggal lain? Kulik latihan SQL di NgulikSQL, dan lanjut baca cara bikin tabel kalender di SQL buat analisa per periode. Detail fungsinya ada di dokumentasi PostgreSQL date/time functions.