Unix Timestamp: apa itu, konversi dan penyimpanan dalam pengembangan mobile

Apa itu Unix Timestamp?

Unix Timestamp (juga dikenal sebagai POSIX time, Epoch time atau Unix time) — adalah sistem pengukuran waktu yang menentukan jumlah detik yang telah berlalu sejak 1 Januari 1970 00:00:00 UTC (era Unix). Tanggal ini dipilih sebagai awal penghitungan untuk sistem operasi Unix, dan kemudian formatnya menjadi standar de facto untuk representasi waktu dalam sistem komputer. Timestamp tidak memperhitungkan detik kabisat — setiap menit dihitung sebagai 60 detik, meskipun Layanan Rotasi Bumi Internasional terkadang menambahkan detik tambahan untuk mengoreksi waktu atom.

Era Unix: mengapa tahun 1970?

Pemilihan 1 Januari 1970 terkait dengan sejarah pengembangan sistem operasi Unix. Pengembang Ken Thompson dan Dennis Ritchie memilih tanggal ini sebagai titik awal yang sederhana dan bulat — tanggal ini cukup awal untuk mencakup semua kemungkinan tanggal, dan pada saat yang sama cukup akhir agar waktu dapat disimpan dalam bilangan bulat bertanda 32-bit. Awalnya waktu diukur dalam seperenam puluh detik, kemudian dalam tick (1/60 detik), dan baru pada edisi ketujuh Unix (V7, 1979) formatnya stabil sebagai jumlah detik penuh. Menurut The Open Group Base Specifications (Issue 8, 2024), sistem yang kompatibel dengan POSIX wajib mendukung format ini.

Bagaimana Cara Kerja Unix Timestamp

Prinsip kerja Unix Timestamp didasarkan pada penghitung sederhana: setiap hari yang berlalu menambahkan 86 400 detik ke nilai. Misalnya, timestamp 1 720 000 000 sesuai dengan tanggal di pertengahan tahun 2024 — konversi tepat dapat dilakukan dengan membagi dengan jumlah detik dalam sehari, jam, dan menit. Pendekatan semacam itu membuat timestamp ideal untuk penyimpanan mesin: ini adalah bilangan bulat yang memakan 4 byte (int 32-bit) atau 8 byte (long 64-bit) dan mendukung perbandingan langsung — timestamp lebih besar = tanggal lebih akhir.

Matematika Konversi

Satu hari = 86 400 detik (24 x 60 x 60). Satu jam = 3600 detik. Untuk mengonversi timestamp ke tanggal, Anda perlu menghitung secara berurutan jumlah hari, jam, menit, dan detik dari awal era. Konversi terbalik — ubah tanggal menjadi hari sejak 1970-01-01, lalu kalikan dengan 86 400 dan tambahkan offset dari UTC. Di Java dan Kotlin, perhitungan ini sudah diimplementasikan dalam kelas standar java.time.Instant dan java.util.Date, yang membebaskan pengembang dari perhitungan manual.

        // Dapatkan Unix Timestamp dalam detik
val seconds = System.currentTimeMillis() / 1000

// Konversi timestamp ke tanggal melalui java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Kebalikan: tanggal ke timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Konversi Unix Timestamp ke Tanggal dan Sebaliknya

Konversi Unix Timestamp ke tanggal yang dapat dibaca manusia adalah salah satu operasi paling umum dalam pengembangan seluler. Di Android, tersedia beberapa metode konversi tergantung pada versi API minimum: untuk API 26+ disarankan java.time.Instant, untuk versi yang lebih tua digunakan java.util.Date dan java.text.SimpleDateFormat. Penting untuk diingat bahwa Android dan JVM secara default menggunakan milidetik, bukan detik — jika timestamp diterima dari server dalam detik, maka harus dikalikan dengan 1000 sebelum diteruskan ke konstruktor standar.

Konversi dengan Zona Waktu Pengguna

Salah satu keunggulan utama Unix Timestamp adalah independensinya dari lokasi. Server selalu mengembalikan timestamp dalam UTC, dan konversi ke tanggal dan waktu lokal dilakukan di sisi klien. Di Kotlin, untuk ini digunakan ZonedDateTime dengan ZoneId yang sesuai — sistem atau yang dipilih oleh pengguna. Jika aplikasi menampilkan waktu di zona yang berbeda (misalnya, untuk pelancong), timestamp menghilangkan kebutuhan untuk mengirimkan zona waktu dari server — satu stempel waktu sudah cukup.

// Konversi dengan zona waktu pengguna
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Contoh: timestamp = 1720000000, zona = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Masalah Tahun 2038

Masalah Tahun 2038 (Year 2038 Problem, Y2K38) — adalah keterbatasan mendasar bilangan bulat bertanda 32-bit untuk menyimpan Unix Timestamp. Nilai maksimum signed int 32-bit adalah 2 147 483 647, yang sesuai dengan 19 Januari 2038 pukul 03:14:07 UTC. Setelah tanggal ini, nilai akan meluap dan berubah menjadi bilangan negatif, yang menyebabkan kegagalan dalam sistem yang menggunakan time_t 32-bit. Masalah ini mirip dengan Y2K yang terkenal, tetapi terutama mempengaruhi sistem tertanam, versi Android lama, dan perangkat IoT dengan arsitektur 32-bit.

Skala Masalah

Menurut Linux Foundation (2025), sekitar 15% perangkat Linux di segmen industri dan IoT masih menggunakan kompilasi 32-bit. Untuk perangkat Android, risikonya lebih rendah — sebagian besar ponsel pintar modern berjalan pada prosesor 64-bit (ARM64), tetapi model lama dengan Android 4.x dan di bawahnya mungkin menggunakan time_t 32-bit. Solusi masalah — migrasi ke time_t 64-bit, yang aman hingga 292 miliar tahun. Mulai Android 5.0 (API 21), semua perangkat menggunakan waktu 64-bit di tingkat kernel. Pengembang aplikasi seluler cukup menyimpan timestamp dalam tipe Long (64-bit) untuk menghindari masalah di tingkat aplikasi.

Bekerja dengan Unix Timestamp di Android

Dalam pengembangan Android, bekerja dengan benar dengan Unix Timestamp sangat penting untuk sinkronisasi data, menampilkan waktu penerimaan pesan, menghitung batas waktu, dan menjadwalkan notifikasi. Panggilan sistem System.currentTimeMillis() mengembalikan waktu saat ini dalam milidetik sejak era Unix — ini adalah sumber waktu paling akurat yang tersedia di perangkat. Untuk permintaan jaringan, biasanya digunakan Unix Timestamp dalam detik, karena sebagian besar REST API dan database beroperasi tepat dengan detik.

Praktik yang Direkomendasikan

Jangan pernah menggunakan System.currentTimeMillis() untuk mengukur interval — untuk ini ada System.nanoTime(), yang monoton dan tidak tergantung pada perubahan jam oleh pengguna. Untuk menampilkan waktu, selalu simpan timestamp dalam UTC dan konversikan ke zona waktu lokal di sisi antarmuka. Saat bekerja dengan database (SQLite, Room), gunakan tipe INTEGER dan simpan timestamp dalam detik — ini memakan 8 byte (Long) dan mendukung pengurutan SQL native. Untuk serialisasi dalam JSON, disarankan mengirim timestamp sebagai angka (Long), bukan string — ini lebih ringkas dan lebih cepat di-parse.

// Pengukuran waktu eksekusi yang benar
val start = System.nanoTime()
// ... operasi ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Simpan di Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp dalam detik
)

Penanganan Waktu dari Server

Saat menerima Unix Timestamp dari server, selalu periksa satuan pengukuran: beberapa API mengembalikan milidetik (kompatibel dengan JavaScript), yang lain — detik (standar POSIX). Kesepakatan tentang satuan harus dicatat dalam dokumentasi API. Dalam respons server, timestamp dapat dikirim sebagai Long (angka JSON) atau String (ISO 8601). Untuk debugging, tambahkan fungsi utilitas yang menampilkan timestamp dalam format yang dapat dibaca manusia — ini menyederhanakan pemeriksaan kebenaran stempel waktu selama pengembangan.

Penyimpanan Stempel Waktu di Database

Pemilihan format penyimpanan waktu di database secara langsung mempengaruhi kinerja kueri, kompleksitas kode, dan kebenaran kerja dengan zona waktu. Unix Timestamp — format paling efisien untuk database relasional: disimpan sebagai bilangan bulat (4 atau 8 byte), mendukung pengindeksan dan pengurutan cepat. Tidak seperti string ISO 8601, timestamp tidak memerlukan parsing saat pengurutan dan memakan lebih sedikit ruang di indeks. Untuk Room dan SQLite, disarankan menyimpan timestamp dalam tipe INTEGER dan menggunakan indeks pada kolom waktu.

Rekomendasi untuk Proyek Mobile

Untuk aplikasi Android dengan pustaka Room, disarankan menyimpan timestamp sebagai Long (64-bit) dan menggunakan TypeConverter untuk konversi otomatis antara Long dan Date atau Instant. Dalam kueri database, gunakan operator perbandingan (>, <, BETWEEN) — mereka bekerja secara native dengan tipe numerik. Untuk penyimpanan sementara data yang memerlukan pengurutan berdasarkan waktu (misalnya, daftar pesan), wajib buat indeks pada kolom timestamp — ini akan mempercepat kueri dengan ORDER BY beberapa kali lipat pada volume data yang besar.