PHP & mySQL: Bug Tahun 2038: Apa itu? Bagaimana cara mengatasinya?

Saya berpikir untuk menggunakan TIMESTAMP untuk menyimpan tanggal + waktu, tetapi saya membaca bahwa ada batasan tahun 2038 di situ. Alih-alih menanyakan pertanyaan saya secara massal, saya lebih suka memecahnya menjadi bagian-bagian kecil agar mudah dipahami oleh pengguna pemula juga. Jadi pertanyaan saya:

1. Apa sebenarnya masalah Tahun 2038?
2. Mengapa itu terjadi dan apa yang terjadi?
3. Bagaimana kita mengatasinya?
4. Apakah ada alternatif lain yang mungkin untuk digunakan, yang tidak menimbulkan masalah serupa?
5. Apa yang dapat kita lakukan untuk aplikasi yang sudah ada yang menggunakan TIMESTAMP, untuk menghindari masalah yang disebut, ketika itu benar-benar terjadi?

Terima kasih sebelumnya.

Saya telah menandai ini sebagai wiki komunitas jadi silakan mengeditnya kapan saja.

Apa sebenarnya masalah Tahun 2038?

"Masalah tahun 2038 (juga dikenal sebagai Unix Millennium Bug, Y2K38 dengan analogi masalah Y2K) dapat menyebabkan beberapa perangkat lunak komputer gagal sebelum atau di tahun 2038. Masalah tersebut mempengaruhi semua perangkat lunak dan sistem yang menyimpan waktu sistem sebagai 32 yang ditandatangani -bit integer, dan tafsirkan angka ini sebagai jumlah detik sejak 00:00:00 UTC pada 1 Januari 1970. "

Mengapa itu terjadi dan apa yang terjadi?

Waktu setelah 03:14:07 UTC pada hari Selasa, 19 Januari 2038 akan 'membungkus' dan disimpan secara internal sebagai angka negatif, yang akan ditafsirkan oleh sistem ini sebagai waktu pada 13 Desember 1901 daripada pada 2038. Hal ini disebabkan oleh fakta bahwa jumlah detik sejak masa UNIX (1 Januari 1970 00:00:00 GMT) akan melebihi nilai maksimum komputer untuk bilangan bulat bertanda 32-bit.

Bagaimana kita mengatasinya?

• Gunakan tipe data yang panjang (64 bit sudah cukup)
• Untuk MySQL (atau MariaDB), jika Anda tidak memerlukan informasi waktu, pertimbangkan untuk menggunakan DATEjenis kolom. Jika Anda membutuhkan akurasi yang lebih tinggi, gunakan DATETIMEdaripada TIMESTAMP. Berhati-hatilah karena DATETIMEkolom tidak menyimpan informasi tentang zona waktu, jadi aplikasi Anda harus mengetahui zona waktu mana yang digunakan.
• Solusi lain yang mungkin dijelaskan di Wikipedia
• Tunggu hingga pengembang MySQL memperbaiki bug ini yang dilaporkan lebih dari satu dekade lalu.

Apakah ada alternatif lain yang mungkin untuk digunakan, yang tidak menimbulkan masalah serupa?

Cobalah sedapat mungkin untuk menggunakan tipe besar untuk menyimpan tanggal dalam database: 64-bit sudah cukup - tipe panjang yang panjang di GNU C dan POSIX / SuS, atau sprintf('%u'...)dalam PHP atau ekstensi BCmath.

Apa sajakah kasus penggunaan yang berpotensi merusak meskipun kami belum berada di tahun 2038?

Jadi MySQL DATETIME memiliki kisaran 1000-9999, tetapi TIMESTAMP hanya memiliki kisaran 1970-2038. Jika sistem Anda menyimpan tanggal lahir, tanggal mendatang (mis. Hipotek 30 tahun), atau serupa, Anda sudah akan mengalami bug ini. Sekali lagi, jangan gunakan TIMESTAMP jika ini akan menjadi masalah.

Apa yang dapat kita lakukan untuk aplikasi yang sudah ada yang menggunakan TIMESTAMP, untuk menghindari masalah yang disebut, ketika itu benar-benar terjadi?

Beberapa aplikasi PHP masih akan ada pada tahun 2038, meskipun sulit untuk meramalkan karena web bukanlah platform lama.

Berikut adalah proses untuk mengubah kolom tabel database untuk mengkonversi TIMESTAMPke DATETIME. Ini dimulai dengan membuat kolom sementara:

# rename the old TIMESTAMP field
ALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;

# create a new DATETIME column of the same name as your old column
ALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;

# update all rows by populating your new DATETIME field
UPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);

# remove the temporary column
ALTER TABLE `myTable` DROP `temp_myTimestamp`

Sumber daya

• Soal Tahun 2038 (Wikipedia)
• Internet Akan Berakhir dalam 30 Tahun

Saat menggunakan Stempel Waktu UNIX untuk menyimpan tanggal, Anda sebenarnya menggunakan bilangan bulat 32 bit, yang menghitung jumlah detik sejak 1970-01-01; lihat Waktu Unix

Angka 32 bit itu akan meluap pada tahun 2038. Itulah masalah tahun 2038.

Untuk mengatasi masalah itu, Anda tidak boleh menggunakan stempel waktu UNIX 32 bit untuk menyimpan tanggal Anda - yang berarti, saat menggunakan MySQL, Anda tidak boleh menggunakan TIMESTAMP, tetapi DATETIME(lihat 10.3.1. Jenis DATETIME, DATE, dan TIMESTAMP ):

The DATETIMEjenis digunakan ketika Anda membutuhkan nilai-nilai yang mengandung kedua tanggal dan informasi waktu. Rentang yang didukung adalah '1000-01-01 00:00:00'untuk '9999-12-31 23:59:59'.

The TIMESTAMPtipe data memiliki berbagai '1970-01-01 00:00:01'UTC ke '2038-01-19 03:14:07'UTC.

Hal (mungkin) terbaik yang dapat Anda lakukan untuk aplikasi Anda untuk menghindari / memperbaiki masalah tersebut adalah dengan tidak menggunakan TIMESTAMP, tetapi DATETIMEuntuk kolom yang harus berisi tanggal yang bukan antara tahun 1970 dan 2038.

Namun, ada satu catatan kecil: kemungkinan besar (secara statistik) aplikasi Anda akan ditulis ulang beberapa kali sebelum tahun 2038 ^^ Jadi mungkin, jika Anda tidak harus berurusan dengan tanggal di masa mendatang , Anda tidak perlu menangani masalah itu dengan versi aplikasi Anda saat ini ...

Pencarian cepat di Google akan berhasil: Masalah tahun 2038

1. Masalah tahun 2038 (juga dikenal sebagai Unix Millennium Bug, Y2K38 dengan analogi masalah Y2K) dapat menyebabkan beberapa perangkat lunak komputer gagal sebelum atau di tahun 2038
2. Masalah ini memengaruhi semua perangkat lunak dan sistem yang menyimpan waktu sistem sebagai bilangan bulat 32-bit yang ditandatangani, dan menafsirkan angka ini sebagai jumlah detik sejak 00:00:00 UTC pada 1 Januari 1970. Waktu terbaru yang dapat direpresentasikan dengan cara ini adalah 03:14:07 UTC pada hari Selasa, 19 Januari 2038. Waktu di luar momen ini akan "membungkus" dan disimpan secara internal sebagai angka negatif, yang akan diinterpretasikan oleh sistem ini sebagai tanggal pada tahun 1901 bukan 2038
3. Tidak ada perbaikan yang mudah untuk masalah ini untuk kombinasi CPU / OS yang ada, sistem file yang ada, atau format data biner yang ada

http://en.wikipedia.org/wiki/Year_2038_problem memiliki sebagian besar detail

Singkatnya:

1) + 2) Masalahnya adalah banyak sistem menyimpan info tanggal sebagai int 32-bit yang ditandatangani sama dengan jumlah detik sejak 1/1/1970. Tanggal terakhir yang dapat disimpan seperti ini adalah 03:14:07 UTC pada hari Selasa, 19 Januari 2038. Jika ini terjadi, int akan "membungkus" dan disimpan sebagai angka negatif yang akan diartikan sebagai tanggal pada tahun 1901. Apa sebenarnya yang akan terjadi kemudian, bervariasi dari sistem ke sistem tetapi cukup untuk mengatakan itu mungkin tidak akan baik untuk mereka!

Untuk sistem yang hanya menyimpan tanggal di masa lalu, maka saya rasa Anda tidak perlu khawatir untuk sementara waktu! Masalah utamanya adalah dengan sistem yang bekerja dengan tanggal di masa depan. Jika sistem Anda perlu bekerja dengan tanggal 28 tahun ke depan maka Anda harus mulai khawatir sekarang!

3) Gunakan salah satu format tanggal alternatif yang tersedia atau pindah ke sistem 64-bit dan gunakan int 64-bit. Atau untuk database menggunakan format cap waktu alternatif (misalnya untuk MySQL gunakan DATETIME)

4) Lihat 3!

5) Lihat 4 !!! ;)

Saudaraku, jika Anda perlu menggunakan PHP untuk menampilkan cap waktu, ini adalah solusi PHP TERBAIK tanpa mengubah dari format UNIX_TIMESTAMP.

Gunakan fungsi custom_date (). Di dalamnya, gunakan DateTime. Inilah solusi DateTime .

Selama Anda memiliki UNSIGNED BIGINT (8) sebagai cap waktu Anda di database. Selama Anda memiliki PHP 5.2.0 ++

Karena saya tidak ingin mengupgrade apa pun, saya meminta backend (MSSQL) saya untuk melakukan pekerjaan ini alih-alih PHP!

$qry = "select DATEADD(month, 1, :date) next_date ";
$rs_tmp = $pdo->prepare($qry);
$rs_tmp->bindValue(":date", '2038/01/15');
$rs_tmp->execute();
$row_tmp = $rs_tmp->fetch(PDO::FETCH_ASSOC);

echo $row_tmp['next_date'];

Mungkin bukan cara yang efisien, tetapi berhasil.