Debian beralih sepenuhnya ke sistem waktu 64-bit tanpa menunggu masalah tahun 2038

• Debian secara resmi menerapkan time_t 64-bit hingga pada arsitektur 32-bit mulai Debian 13 versi berikutnya untuk memblokir lebih awal masalah Y2K38 (Unix Epochalypse)
• Karena keterbatasan time_t 32-bit yang ada saat ini, setelah 19 Januari 2038 waktu bisa berbalik ke tahun 1900, sehingga masalah ini diputuskan untuk tidak lagi dibiarkan
• Perangkat keras 64-bit sudah aman, tetapi kebutuhan terhadap Debian masih ada pada perangkat 32-bit yang sensitif terhadap biaya seperti embedded dan IoT, sehingga penting untuk menangani ini lebih awal
• Pekerjaan berskala besar sedang dilakukan dengan mengalihkan secara serentak tipe time_t yang tersebar di total 6.429 paket, sambil menerima bahwa kompatibilitas ABI akan terputus sekali ini
• Beberapa arsitektur dukungan lawas seperti i386 dan hurd-i386 tetap menjadi pengecualian, namun kemungkinan pengenalan arsitektur x86 (i686) baru berbasis time_t 64-bit juga disebutkan

---

Penanganan bug Y2K38 oleh Debian: beralih ke waktu 64-bit

• Debian beralih ke waktu 64-bit di semua lingkungan, kecuali pada sebagian perangkat keras tertua yang masih didukung, untuk menghindari masalah Y2K38 atau Unix Epochalypse yang akan datang
• Dengan ini, Debian mencegah kesalahan nilai waktu akibat melampaui rentang signed int 32-bit yang diperkirakan terjadi pada 19 Januari 2038

Latar belakang masalah Y2K38 dan Unix Epochalypse

• Masalah Y2K38 adalah fenomena pada sistem Unix yang merepresentasikan detik yang berlalu sejak 1 Januari 1970 dengan signed int 32-bit; setelah melewati tahun 2038, overflow dapat terjadi sehingga waktu salah kembali ke masa lalu seperti tahun 1900
• Ini berasal dari keputusan arsitektural yang memilih format data pendek, mirip dengan masalah Y2K (masalah tahun 2000) di masa lalu
• Pada saat Y2K, kekacauan besar dapat dicegah berkat penanganan lebih awal oleh para pengembang
• Perangkat lunak untuk perangkat keras 64-bit sudah aman, tetapi Debian masih banyak digunakan di lingkungan embedded, spesifikasi rendah, dan sistem lawas

Respons utama Debian

• Mulai rilis Debian 13 "Trixie", time_t 64-bit diterapkan sebagai nilai default di semua arsitektur utama
• Perangkat keras 64-bit memang sudah aman, namun masalah ini sering muncul pada perangkat embedded berbasis prosesor 32-bit dan perangkat keras lawas
• Perangkat seperti ini masih digunakan di bidang yang sensitif terhadap biaya dan dikirim dalam jumlah besar, seperti kontrol otomotif, IoT, TV, dan router
• Banyak perangkat baru memakai Linux build mandiri seperti OpenEmbedded, Alpine, Android, dan Gentoo, namun penggunaan perangkat embedded berbasis Debian diperkirakan tetap berlanjut dalam beberapa tahun ke depan

Penerapan dan perubahan

• Variabel time_t tersebar di 6.429 paket, sehingga dibutuhkan pekerjaan berskala besar
• Karena perubahan ini dapat merusak kompatibilitas ABI (application binary interface), penyesuaian dilakukan secara serentak pada semua pustaka dan paket terkait
• Menurut tim pemeliharaan, pekerjaan tersebut telah selesai dan diuji dengan cukup baik

Pengecualian dan rencana ke depan

• Port i386 (x86 lama) tetap mempertahankan time_t 32-bit demi kompatibilitas menjalankan biner lama
• Penerapan waktu 64-bit dan ISA (instruction set architecture) modern pada arsitektur i686 dapat dibahas secara terpisah
• Port hurd-i386 tidak dialihkan karena dukungan kernel belum memadai; sebagai gantinya, upaya pemindahan ke hurd-amd64 sedang berlangsung

Catatan untuk pengembang

• Pengembang dapat menguji apakah perangkat lunak mereka akan rusak akibat penerapan variabel waktu 64-bit melalui panduan yang disediakan di wiki Debian
• Detail lebih lanjut dan dokumen teknis tersedia di Debian wiki

[GN⁺]

Komentar Hacker News

• Steve Langasek memusatkan diri untuk menyelesaikan masalah ini pada beberapa tahun terakhir hidupnya dan mendorong kemajuan besar; setiap kali melihat time_t 64-bit nanti, saya akan teringat padanya
  • Terima kasih sudah mengabarkan kabar baik ini lagi, saya rindu Steve; saya jadi penasaran apakah Joey masih aktif di Debian
• Soal masalah Y2K (masalah tahun 2000 akibat representasi tahun 2 digit), saat itu penghematan 2 byte memang sangat berharga, dan perangkat lunak era 70-an hingga 90-an berubah cepat sehingga orang tidak berharap dipakai lebih dari 5 tahun; sudut pandang yang terlalu meremehkan rasanya kurang adil
  • Bahkan sekarang pun tahun 2 digit masih sering dipakai; misalnya tanggal kedaluwarsa kartu kredit (mm/yy) lebih praktis jika ditulis singkat, jadi representasi tahun 2 digit dipakai; itu cukup untuk umur kartu, tetapi pada 2100 bisa memunculkan masalah konversi; sebagian besar Y2K berasal dari masalah UI (text field dua karakter, hardcode +1900, dll.), dan bug Y2K yang pernah saya alami langsung adalah forum internet yang berpindah dari 1999 ke 19100 (sekadar kesalahan tampilan); Y2K bukan hanya masalah COBOL
  • Dalam kasus seperti ini, “optimisasi prematur” justru mungkin akan membantu; kalau tanggal direpresentasikan sebagai nilai int sederhana dengan 0 di tahun 1900, byte yang dihemat malah bisa lebih banyak; dengan 3 byte bisa mencakup dari 1900 sampai sekitar tahun 44.000, dan dengan 2 byte pun masih bisa menjangkau sampai sekitar 2070
  • Yang sering membingungkan orang adalah bukan menambah 2 byte, melainkan harus menambah 2 karakter; di COBOL, baik angka maupun data dialokasikan dalam lebar tetap sebesar ukuran karakter, jadi untuk memasukkan tahun 4 digit diperlukan 4 posisi karakter; ukuran field seperti ini di-hardcode ke seluruh program seperti akses data, UI, batch file, file perantara, file transfer, dan sebagainya
  • Tepat sebelum Y2K, ada kenalan saya yang membeli banyak opsi put karena berharap harga saham bank-bank besar akan anjlok, tetapi pada praktiknya hampir tidak terjadi hal besar
  • Saat bekerja dengan COBOL pada akhir 80-an, saya pernah melihat program yang hanya menyimpan tahun 1 digit; ketika dijelaskan strukturnya saya merasa aneh, tetapi catatannya otomatis dihapus setiap 4 tahun sehingga dalam penggunaan tidak menimbulkan masalah; selalu jelas tahun mana yang dimaksud
• time_t 64-bit akan menyelesaikan Epochalypse, tetapi tidak semua sistem sekadar berpindah ke detik 64-bit; ext4 sudah berubah ke resolusi pecahan 30-bit (setingkat nanodetik) dan resolusi detik 34-bit, tetapi beberapa ratus tahun lagi masalah serupa tetap akan muncul lagi; saya memperkirakan suatu saat kita akan menetap pada timestamp 128-bit berupa 64-bit detik + 64-bit pecahan, dan itu akan mencakup seluruh masa depan yang dapat diperkirakan dalam sejarah manusia
  • Waktu detik 64-bit setara dengan sekitar 585 miliar tahun, hasil perhitungan WolframAlpha
  • Bahkan resolusi pecahan 64-bit pun mungkin belum cukup; untuk mendekati waktu Planck, perlu sampai 144 bit
  • Saya jadi penasaran dengan timestamp ext4, dan juga ingin tahu bagaimana filesystem zfs dan btrfs menangani waktu; btrfs mungkin memakai 64-bit, dan zfs juga (mungkin saya tertukar dengan ext4) saya harap mirip
• Debian katanya sedang menyelesaikan Y2K38, yaitu masalah Unix Epochalypse, tetapi sebenarnya pada semua port 32-bit selain i386, transisi ke time64_t sudah selesai; hanya i386 yang menjadi pengecualian demi kompatibilitas biner lama, dan sisanya termasuk m68k semuanya sudah diubah; saya sendiri yang memindahkan m68k, powerpc, sh4, dan hppa
• time_t bukan variabel, melainkan tipe data
  • Isi di artikel itu berdasarkan wiki Debian; di teks aslinya tertulis, “time_t benar-benar muncul di mana-mana. Dari 35.960 paket, ia muncul di source code 6.429 paket. Paket yang mengekspos struct yang berisi time_t sebagai ABI harus memigrasikan seluruh ABI secara serempak”; wiki menjelaskannya lebih jelas daripada artikelnya
  • “For everything” disebutkan berlaku untuk armel, armhf, hppa, m68k, powerpc, sh4, dan bukan i386; i386 tidak punya masa depan, dan tujuan utamanya adalah menjalankan biner/library dinamis lama sehingga tidak diinginkan rusak
  • “Akan diterapkan setelah rilis Debian 13 Trixie” sebenarnya berarti termasuk dalam Trixie
• Akan bagus juga jika batas panjang command line dibuat tanpa batas/dinamis; saya punya memori 96GB tetapi tetap sering terganggu error “argument list too long”
  • Anda bisa mengompilasi ulang kernel untuk menghapus batas panjang command line (sekitar 100 ribu karakter), lihat stackoverflow, tetapi rasanya itu bukan solusi mendasar; saya juga bingung argumen sepanjang file JPEG 4k mau dipakai untuk apa
  • Cukup tingkatkan nilai RLIMIT_STACK, misalnya ulimit -s 4000 berarti stack 4MB; kalau ingin lebih besar, ubah /etc/security/limits.conf lalu login ulang
  • Mungkin bisa dipaketkan ke Electron lalu dikirim sebagai request http post json
  • Bisa juga dengan mendefinisikan ulang MAX_ARG_STRLEN lalu mengompilasi ulang kernel; memakai mesin dengan page size lebih besar (misalnya kernel RHEL Arm dengan page size 64k) juga bisa jadi cara; tetapi jauh lebih mudah memakai pipe alih-alih command buffer untuk mengirim data antarproses
  • Batas path file juga masalah serupa; pada beberapa build system (Debian + python + dh-virtualenv, dll.), path bisa menjadi sangat panjang, jadi lebih nyaman kalau dibiarkan saja
• Meski sudah diubah ke 64-bit, suatu saat batas itu tetap akan datang; saya penasaran apa yang akan dilakukan manusia pada 4 Desember 292277026596 pukul 15:30:07 (UTC)
  • Mungkin saat itu kita sedang merayakan 100 tahun adopsi penuh ipv6
  • Dalam waktu kurang dari 5 miliar tahun, matahari akan menjadi raksasa merah dan seluruh permukaan bumi akan menguap
  • Semoga saat itu kita sudah pindah ke sistem kalender yang lebih baik, meskipun tentu masalah timestamp masih akan tetap ada
  • Tinggal beralih ke waktu 128-bit
  • Mungkin RFC 2550 (Y10K & beyond) bisa diterapkan; dipublikasikan pada 1 April 1999
• Sudah 11 tahun sejak OpenBSD 5.5 menerapkan perubahan yang sama, catatan rilis OpenBSD 5.5
  • Ini kasus yang mengungguli semua orang; pada era 90-an saya menemukan bahwa API 32-bit OS/2 mengembalikan waktu 64-bit, lalu saya menulis sendiri library standar C++ dengan time_t 64-bit dan memakainya
  • Agak di luar topik, tetapi pada saat seperti ini saya jadi ingin mengganti server ke OpenBSD alih-alih Linux
  • OpenBSD bisa lebih sedikit memikirkan kompatibilitas, dan jumlah penggunanya juga jauh lebih kecil, sehingga kemungkinan bug atau edge case saat perubahan terjadi menjadi lebih rendah
• Kalau dikatakan “Debian sekarang sudah cukup matang dan teruji, jadi akan dialihkan setelah rilis Trixie”, apakah itu berarti tidak diterapkan di Trixie?
  • Di catatan rilis Trixie tertulis akan diterapkan, catatan rilis Trixie
• Ini pertama kalinya saya mendengar Y2K38 disebut Unix Epochalypse, tetapi namanya lucu jadi mungkin bisa menyebar
  • Nama itu juga muncul di Wikipedia Year 2038 Problem, dan sejak 2017 menyebar sebagai lelucon
  • Ada juga proyek epochalypse-project.org
  • Ungkapan “it’s kind of fetch” tampaknya merupakan referensi/ledekan dari film Mean Girls
  • Tersisa sekitar 12 tahun 5 bulan 22 hari 13 jam 22 menit hingga Epochalypse