Saya telah menandai ini sebagai wiki komunitas, jadi silakan edit sesuka Anda.
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 pada tahun 2038. Masalah mempengaruhi semua perangkat lunak dan sistem yang menyimpan waktu sistem sebagai tanda 32 -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 ketika itu terjadi?
Waktu di luar 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 dan bukan pada 2038. Hal ini disebabkan oleh fakta bahwa jumlah detik sejak zaman UNIX (1 Januari 1970 00:00:00 GMT) akan melebihi nilai maksimum komputer untuk bilangan bulat bertanda 32-bit.
Bagaimana cara mengatasinya?
- Gunakan tipe data yang panjang (64 bit sudah cukup)
- Untuk MySQL (atau MariaDB), jika Anda tidak membutuhkan informasi waktu, pertimbangkan untuk menggunakan
DATE
jenis kolom. Jika Anda membutuhkan akurasi yang lebih tinggi, gunakanDATETIME
daripadaTIMESTAMP
. Hati-hati bahwaDATETIME
kolom tidak menyimpan informasi tentang zona waktu, jadi aplikasi Anda harus mengetahui zona waktu mana yang digunakan. - Solusi lain yang mungkin dijelaskan di Wikipedia
- Tunggu sampai pengembang MySQL memperbaiki bug ini dilaporkan lebih dari satu dekade lalu.
Apakah ada alternatif yang memungkinkan untuk menggunakannya, yang tidak menimbulkan masalah serupa?
Cobalah sedapat mungkin menggunakan tipe besar untuk menyimpan tanggal dalam database:64-bit sudah cukup - tipe panjang dan panjang di GNU C dan POSIX/SuS, atau sprintf('%u'...)
dalam PHP atau ekstensi BCmath.
Apa saja kasus penggunaan yang berpotensi melanggar meskipun kita belum memasuki tahun 2038?
Jadi MySQL DATETIME memiliki kisaran 1000-9999, tetapi TIMESTAMP hanya memiliki kisaran 1970-2038. Jika sistem Anda menyimpan tanggal lahir, tanggal mendatang (misalnya hipotek 30 tahun), atau serupa, Anda sudah akan mengalami bug ini. Sekali lagi, jangan gunakan TIMESTAMP jika ini akan menjadi masalah.
Apa yang bisa kita lakukan untuk aplikasi yang ada yang menggunakan TIMESTAMP, untuk menghindari apa yang disebut masalah, padahal itu benar-benar terjadi?
Beberapa aplikasi PHP akan tetap ada pada tahun 2038, meskipun sulit untuk diperkirakan karena web belum menjadi platform lama.
Berikut adalah proses untuk mengubah kolom tabel database untuk mengkonversi TIMESTAMP
ke DATETIME
. 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