Masalah tahun 2038 [ditutup]

Apa kemungkinan masalah Tahun 2038 menjadi sangat bermasalah?

Saya telah mengalami masalah ini dalam sistem Linux tertanam yang perlu menangani tanggal melewati 2038 dalam beberapa sertifikat kriptografi jangka panjang, jadi saya akan mengatakan kesamaan ini tergantung pada domain aplikasi Anda.

Meskipun sebagian besar sistem harus siap sebelum 2038, jika Anda menemukan diri Anda hari ini menghitung tanggal jauh di masa depan, Anda mungkin memiliki masalah.

Saya pikir ini akan menjadi masalah yang signifikan, jauh lebih merusak daripada masalah Y2K pada tahun 1999/2000 karena kode yang terpengaruh umumnya lebih rendah (CTIME) dan jadi lebih sulit untuk menemukan tempat-tempat di mana waktu disimpan dengan cara itu.

Untuk memperumit masalah lebih lanjut, fakta bahwa Y2K dianggap sebagai squib yang lembab akan membuat lebih sulit untuk menarik perhatian pada masalah dalam rangkaian acara.

Referensi budaya:

Cory Doctorow sedang mencoba model baru untuk komisioning / penerbitan cerita pendek di bawah lisensi terbuka, dan saya menyarankan tema 2038 salah satunya, yang ia lakukan dengan cemerlang dalam Epoch: http://craphound.com/?p=2337

Beberapa tahun yang lalu, sudah ada laporan masalah, di bidang-bidang seperti program hipotek melakukan perhitungan pinjaman 30 tahun: 2008 + 30 = 2038.

OS 64 bit pada akhirnya tidak relevan dengan masalah 2037. (CTIME berjalan lebih dekat ke 2037 dari 2038).

Pertanyaannya bukan pada kedalaman bit OS, melainkan bagaimana waktu penyimpanan OS. Atau bagaimana kolom database memilih untuk menyimpan waktu. Atau bagaimana sintaks waktu layanan direktori ini menyimpan waktu di bagian belakang.

Ini adalah masalah yang jauh lebih besar daripada yang dipikirkan orang, karena sangat endemik dan umum menggunakan penghitung waktu 32 bit.

Setiap instance yang menyimpan waktu perlu ditinjau kembali, dan semua API diperbarui, dan semua alat yang menggunakannya juga diperbarui.

Lapisan abstraksi yang memungkinkan Anda mengatur waktu melalui format waktu yang dapat dibaca manusia, alih-alih data mentah yang ditulis membuatnya lebih mudah, tetapi itu hanya satu kasus.

Saya menduga ini akan menjadi kesepakatan yang jauh lebih besar daripada yang dipikirkan kebanyakan orang.

Ini adalah pendapat saya, tetapi masalah ini disebabkan oleh masalah penghitung 32 bit, hari ini sebagian besar os diperbarui untuk menangani waktu pada 64 bit (setidaknya pada komputer 64 bit), jadi saya kira semua OS dan perangkat lunak akan siap untuk waktu yang lama. waktu sebelum 2038, katakanlah tahun 2020. Jadi Anda mungkin hanya memiliki masalah jika pada tahun 2038 Anda masih akan menjalankan perangkat lunak dari tahun 2020.
Kemungkinan tidak menjadi masalah di hampir semua kasus. Saya harap.

Bukan masalah besar.

Selama blitz Y2K pertama, di mana vendor perangkat lunak dan perangkat keras diharuskan untuk mengesahkan produk mereka sebagai "Y2K compliant" agar dapat dijual (Saya ingat kabel jaringan pada PC Connection disertifikasi Y2K compliant), banyak perusahaan melakukan audit terperinci atas segalanya , dengan mengatur jam di masa depan dan pengujian.

Pada saat itu, karena biaya pengujian sangat tinggi, mereka hampir selalu diuji dengan beberapa tanggal, seperti 1/1/99 (beberapa pengembang mungkin menggunakan 99 sebagai sentinal), 12/31/99, 1/1 / 00, lompatan 2000, 1/19/38, dan banyak lainnya. Lihat di sini untuk daftar yang membosankan.

Jadi saya percaya bahwa setiap perangkat lunak penting yang ada sekitar tahun 1999 mungkin tidak akan memiliki 2.038 bug, tetapi perangkat lunak baru yang ditulis sejak saat itu oleh para programmer yang bodoh mungkin. Setelah seluruh programmer Y2K bencana umumnya menjadi lebih sadar akan masalah pengkodean tanggal sehingga tidak akan berdampak sebesar Y2K (yang, dalam dirinya sendiri, merupakan sesuatu yang antiklimaks).

Sistem 32 bit yang masih berjalan saat itu akan menjadi masalah.

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

seharusnya 1 bukan 9 tetapi ctime tidak menangani tanggal yang lebih besar:

8 - Sun Jun 13 07:26:08 1141709097

Sistem saya (tentu saja 64 bit) waktu dapat berjalan bahkan 1 juta tahun lebih. Solusinya adalah memperbarui sistem ke 64 bit.

Tangkapannya adalah bahwa program mungkin tidak menanganinya. Terutama tua, propertary dan tidak terawat. Devs digunakan untuk fakta-fakta berikut:

• intAda 32 bit (sebenarnya mereka disimpan sebagai 32 bit pada sistem 64-bit antara lain karena diasumsikan mereka 32 bit selalu)
• Sebagian besar tipe (seperti time_t) dapat dicast dengan amanint

Dalam perangkat lunak FLOSS yang populer, kedua hal ini mungkin tidak akan melalui tinjauan 'banyak mata'. Pada yang kurang populer dan propertary itu akan sangat tergantung pada penulis.

Saya kira di dunia * nix gratis, 2038 akan mendapatkan 'tanpa diketahui' sementara saya memang mengharapkan masalah pada platform "propertary" (yaitu mereka yang memiliki sejumlah besar perangkat lunak propertary) - terutama jika beberapa bagian crutial tidak akan dipertahankan.

Jika itu seperti Y2K, beberapa orang telah terpengaruh dan sedang mengubah perangkat lunak, tetapi sebagian besar pengembang akan mengabaikannya sampai sekitar tahun 2030-an, mungkin 2035 atau lebih, pada titik mana akan ada banyak pekerjaan yang dilakukan, dan siapa pun yang cukup tua untuk mengetahui K&R C dan belum terlalu pikun tiba-tiba akan bisa mendapatkan banyak uang. Transisi yang sebenarnya akan menunjukkan banyak hal yang belum dilakukan, mungkin tidak ada yang terlalu penting.

Masalah Y2K adalah dua piagam yang mewakili tahun, bukan empat.

Banyak sistem tidak memiliki cara untuk membedakan antara 2000 dari 1900 karena mereka hanya menyimpan '00'.

Hampir semua sistem sekarang menggunakan 4 karakter untuk menyimpan tahun ini, atau mereka menggunakan semacam perpustakaan.

Jadi mari kita semua khawatir tentang tahun 10000 (Y10K) sebagai gantinya. Kecuali untuk penulis OS dan Perpustakaan ...