Clock Drift: Saat Timestamp Berhenti Jadi Bukti

Clock Drift: Saat Timestamp Berhenti Jadi Bukti

Timestamp cuma jadi bukti kalau jam yang menulisnya benar. Di lapangan, biasanya tidak. Kamera, controller akses, dan sensor bertenaga baterai masing-masing menyimpan waktunya sendiri, dan masing-masing melenceng dengan kecepatan berbeda. Begitu ada insiden dan log ketiganya harus disandingkan, yang Anda baca bukan urutan kejadian — melainkan selisih jamnya.

Masalah ini tidak pernah kelihatan sampai dibutuhkan. Dashboard menampilkan apa pun waktu yang dilaporkan perangkat, dan tampak wajar. Ongkosnya baru terasa di hari seseorang bertanya: apa yang terjadi pukul 14:32?

Kenapa jam perangkat lapangan melenceng?

Setiap perangkat yang menyimpan waktu antar-reboot punya real-time clock. Isinya osilator kecil, biasanya kristal kuarsa 32.768 kHz, yang detaknya dihitung terus oleh sebuah counter.

Bayangkan jam dinding warung. Tidak ada yang rusak dari jamnya; ia cuma tidak pernah dicocokkan ke apa pun. Enam bulan kemudian selisihnya lima menit, dan semua orang di warung itu sudah hafal harus mengurangi berapa.

Kristal kelas konsumen dispesifikasikan sekitar ±20 ppm pada suhu ruang. Angkanya kelihatan sepele sampai dikalikan.

Dua puluh bagian per sejuta dari satu hari — 86.400 detik — sama dengan 1,7 detik. Sebulan berarti 52 detik. Itu pun kasus terbaiknya, untuk perangkat yang duduk manis di rak ber-AC.

Perangkat lapangan tidak duduk di rak ber-AC. Kristal tuning fork mengikuti kurva frekuensi parabolik dengan puncak di sekitar 25 °C, dengan konstanta kelengkungan sekitar −0,034 ppm/°C² (Microchip AN2648). Controller yang terpanggang 50 °C di dalam box rooftop menambah sekitar 21 ppm error di atas toleransi bawaannya — hampir 1,8 detik lagi hilang tiap hari. Arahnya pun selalu sama: berkurang. Parabolanya tidak punya sisi positif.

Ada juga perangkat yang memang tidak punya kristal. Espressif menempatkan osilator RC internal ESP32 di kategori yang "time drifting in the range of several seconds per day is acceptable", dan menyarankan kristal eksternal 32 kHz kalau ketepatan waktu selama deep sleep memang dibutuhkan (ESP-IDF System Time). Untuk sensor baterai yang bangun sejam sekali dan tidak sinkron ke apa pun, beberapa detik per hari jadi hitungan menit dalam dua minggu.

DVR dan NVR punya versinya sendiri. Jamnya disetel manual waktu commissioning, ditopang baterai koin, lalu tidak pernah disentuh lagi. Begitu baterainya habis — dan setelah lima tahun pasti habis — mati listrik berikutnya melempar jamnya ke tanggal default firmware. Perekamnya tetap merekam. Overlay-nya tetap membakar timestamp ke tiap frame. Isinya saja yang sudah salah.

Berapa mahal selisih empat menit?

Sebuah pengelola gedung perlu menyelesaikan sengketa soal siapa yang masuk koridor terbatas. Controller akses punya badge event lengkap dengan nama dan jam. NVR punya rekaman kontinu. Dua sistem, satu pertanyaan, mestinya selesai sepuluh menit.

Playback di jam badge event menampilkan koridor kosong. Menit sebelumnya kosong. Menit sesudahnya juga. Controller-nya domain-joined dan sinkron. NVR-nya jalan dengan RTC sendiri sejak hari pemasangan, dan sudah maju hampir empat menit. Kejadiannya ada di rekaman sejak awal — empat menit lebih cepat dari yang dicari semua orang.

Itu versi murah dari kegagalan ini, karena akhirnya ketahuan. Versi mahalnya: tidak ada yang mengecek, selisihnya kebetulan kecil sehingga terlihat masuk akal, dan rekonstruksi kejadian menempatkan dua peristiwa dalam urutan terbalik.

Korelasi lintas sistem justru alasan log disimpan terpisah. Dan korelasi baru jalan kalau selisih tiap sistem terhadap satu acuan bersama diketahui:

Langkah normalisasi hanya mungkin kalau ada yang mengukur selisihnya sebelum perangkat di-reboot, disinkronkan ulang, atau diganti. Lewat dari itu, angkanya hilang. Timestamp lama tidak akan pernah bisa ditaruh di satu garis waktu bersama lagi.

Apakah cukup dengan memasang NTP?

NTP — protokol yang menyamakan jam perangkat ke jam acuan internet — menyelesaikan soal drift. Ia tidak menyelesaikan soal kepercayaan. Dan di lapangan, sering soal drift-nya pun belum sempat selesai.

Tiga kegagalan menyumbang hampir semua kasus yang saya temukan di lokasi:

• Sinkron cuma saat boot. Banyak firmware embedded memanggil SNTP sekali waktu startup, lalu tidak pernah lagi. Gateway dengan uptime 90 hari berarti 90 hari drift menumpuk, sementara halaman konfigurasinya tetap memajang alamat server NTP dengan percaya diri.
• UDP 123 diblokir ke luar. VLAN kamera dan controller sengaja diisolasi, dan waktu adalah hal yang terlupa di ACL. Perangkatnya sudah dikonfigurasi NTP. Ia belum pernah sekali pun sampai ke server.
• Tidak ada yang memantau offset-nya. Status sinkron itu metrik, sama seperti metrik lain. chronyc tracking memberi offset saat ini dalam detik; ekspor, gambar grafiknya, pasang alert di ambang yang Anda pilih dengan sadar. Tempatnya sama dengan reachability dan uptime di health view fleet — cara membangun lapisan polling-nya dibahas di memantau fleet CCTV dengan SNMP.

Ada juga sisi keamanan, dan urusan yang satu ini masih jauh dari beres — lebih jauh daripada dugaan kebanyakan orang. Di presentasi Februari 2026 yang diliput LWN, Ruben Nijveld menyebut NTP "fundamentally a broken protocol": penyerang di jalur jaringan bisa mengubah timestamp saat transit tanpa terdeteksi. Network Time Security, distandarkan sebagai RFC 8915 pada 2020, menutup celah itu dengan waktu terautentikasi. Adopsinya lambat. Implementasi referensi ntpd belum mendukung NTS sama sekali, dan laporan yang sama mencatat belum ada implementasi SNTP yang mendukungnya. SNTP persis yang dipakai perangkat embedded. Perangkat yang paling sulit ketahuan kalau waktunya dipalsukan justru yang paling belum bisa dilindungi.

Untuk deployment di Indonesia, BMKG menjalankan acuan waktu nasional di ntp.bmkg.go.id berdasarkan UU 31/2009, berdampingan dengan time.bmkg.go.id dan jam.bmkg.go.id (BMKG Tanda Waktu). Sumber stratum lokal menang di round-trip latency. Ia juga memberi jawaban yang bisa dipertanggungjawabkan kalau ada yang menanyakan jam mana yang Anda jadikan acuan.

Bagaimana membuktikan jamnya benar?

Forensik digital punya jawaban formalnya. Di Forensic Science International: Digital Investigation volume 49 (2024), Vanini, Hargreaves, van Beek, dan Breitinger mendefinisikan time anchor: peristiwa yang waktunya dipatok sumber eksternal terpercaya, sehingga pemeriksa bisa menguji jam perangkat terhadap kenyataan dan mengukur skew-nya — bukan menganggapnya sudah beres.

Versi operasionalnya empat kebiasaan:

1. Ukur offset sebelum menyentuh apa pun. chronyc tracking, ntpdate -q pool.ntp.org, atau foto layar jam NVR bersebelahan dengan HP yang menampilkan waktu jaringan. Tulis angkanya di catatan insiden. Kerjanya tiga puluh detik, dan tidak bisa diambil lagi begitu perangkat reboot.
2. Pilih perangkat yang mencatat event sinkronnya sendiri. Measurement log chrony dan systemd-timesyncd sama-sama meninggalkan jejak. Catatan step 228 detik adalah pernyataan langsung bahwa semua timestamp sebelumnya meleset 228 detik.
3. Sediakan satu anchor per sistem yang bisa diverifikasi pihak lain. Struk SMS, callback payment gateway, header Date dari API cloud. Sesuatu yang bisa dikonfirmasi tanpa bergantung pada infrastruktur Anda sendiri.
4. Jangan pernah menulis ulang timestamp lama. Simpan offset hasil pengukuran di sebelahnya, koreksi saat query. Menimpa datanya justru menghapus satu-satunya jejak bahwa data itu pernah salah.

Disiplin yang sama membuat badge event dan video bisa dipakai bersama sejak awal. Sisi integrasinya dibahas di integrasi VMS dan access control.

Apa yang berubah saat leap second dihapus?

Aturan di bawah semua ini sedang ditulis ulang sekarang. Resolusi 4 CGPM (2022) menyatakan nilai maksimum selisih UT1−UTC "will be increased in, or before, 2035" — praktisnya mengakhiri penyisipan leap second. CIPM diminta mengusulkan batas barunya menjelang CGPM ke-28 (BIPM). Pertemuan itu tahun ini.

Di saat yang sama, rotasi Bumi justru mengencang. Makalah Duncan Agnew di Nature (27 Maret 2024) memperkirakan leap second negatif — satu detik dibuang, bukan ditambahkan — mungkin dibutuhkan sekitar 2029 (Nature). Dari 27 leap second yang disisipkan antara 1972 dan 2016, semuanya positif. Belum ada kode produksi di mana pun yang pernah menangani arah sebaliknya.

Empat aturan menjauhkan sistem dari urusan itu:

• Simpan UTC. Bukan waktu lokal, bukan "apa pun yang dilaporkan perangkat". Fleet yang tersebar di WIB, WITA, dan WIT menampilkan satu momen dengan tiga wajah; itu urusan tampilan, bukan format penyimpanan.
• Pakai monotonic clock untuk durasi. CLOCK_MONOTONIC, performance.now(), steady_clock. Watchdog yang mengukur selang waktu pakai wall clock akan melaporkan durasi negatif begitu NTP melangkah mundur.
• Slew, bukan step, di sistem yang sedang jalan. maxslewrate chrony menjaga urutan tetap utuh; simpan makestep untuk saat boot, ketika belum ada yang sedang dihitung waktunya.
• Catat sumber sinkron di baris log. Saat dua sistem berselisih nanti, pertanyaannya jam mana yang dipercaya, dan jawabannya ada di acuan waktu masing-masing.

Checklist lapangan

• Tiap perangkat yang menulis timestamp punya server NTP terkonfigurasi dan jalur yang terbukti sampai. Verifikasi jalurnya, bukan kolom konfigurasinya.
• Sinkron berjalan sebagai daemon, bukan sekali jalan waktu boot.
• Offset jam jadi metrik yang dipantau, dengan ambang alert.
• Penggantian baterai RTC masuk jadwal maintenance bersama komponen lain.
• Node bertenaga baterai tanpa kristal melaporkan ketidakpastiannya sendiri, atau mengirim nomor urut yang di-timestamp server saat tiba.
• Prosedur insiden dimulai dengan mencatat offset tiap perangkat yang terlibat.

Penutup

Timestamp terlihat seperti fakta. Ia sebenarnya hasil pengukuran, dibuat osilator murah di dalam box yang panas, dan menua persis seperti alat ukur lain yang tidak pernah dikalibrasi.

Ongkos mencegahnya nyaris nol selagi sistemnya sehat: satu sumber waktu yang terjangkau, satu daemon yang tetap hidup, satu metrik di dashboard. Ongkos melewatkannya ditagih sekaligus di hari log-log itu harus disandingkan — dan saat itu selisih yang bisa menjelaskan semuanya sudah ikut hilang bersama reboot terakhir.