Tôi đã đánh dấu đây là wiki cộng đồng nên bạn có thể thoải mái chỉnh sửa.
Vấn đề chính xác của Năm 2038 là gì?
"Sự cố năm 2038 (còn được gọi là Unix Millennium Bug, Y2K38 tương tự với sự cố Y2K) có thể khiến một số phần mềm máy tính bị lỗi trước hoặc trong năm 2038. Sự cố này ảnh hưởng đến tất cả phần mềm và hệ thống lưu trữ thời gian hệ thống dưới dạng ký 32 -bit số nguyên và giải thích số này là số giây kể từ 00:00:00 UTC vào ngày 1 tháng 1 năm 1970. "
Tại sao nó xảy ra và điều gì xảy ra khi nó xảy ra?
Thời gian vượt quá 03:14:07 UTC vào Thứ Ba, ngày 19 tháng 1 năm 2038 sẽ 'quấn quanh' và được lưu trữ bên trong dưới dạng số âm, mà các hệ thống này sẽ giải thích là thời điểm vào ngày 13 tháng 12 năm 1901 chứ không phải vào năm 2038. Điều này là do số giây kể từ kỷ nguyên UNIX (ngày 1 tháng 1 1970 00:00:00 GMT) sẽ vượt quá giá trị tối đa của máy tính đối với số nguyên có dấu 32 bit.
Chúng ta giải quyết nó như thế nào?
- Sử dụng các kiểu dữ liệu dài (64 bit là đủ)
- Đối với MySQL (hoặc MariaDB), nếu bạn không cần thông tin thời gian, hãy xem xét sử dụng
DATE
loại cột. Nếu bạn cần độ chính xác cao hơn, hãy sử dụngDATETIME
thay vìTIMESTAMP
. Hãy coi chừng rằngDATETIME
các cột không lưu trữ thông tin về múi giờ, vì vậy ứng dụng của bạn sẽ phải biết múi giờ nào đã được sử dụng. - Các giải pháp khả thi khác được mô tả trên Wikipedia
- Chờ các nhà phát triển MySQL sửa lỗi này được báo cáo hơn một thập kỷ trước.
Có bất kỳ giải pháp thay thế khả thi nào để sử dụng nó không gây ra vấn đề tương tự không?
Hãy thử sử dụng các loại lớn để lưu trữ ngày tháng trong cơ sở dữ liệu ở mọi nơi có thể:64 bit là đủ - loại dài dài trong GNU C và POSIX / SuS, hoặc sprintf('%u'...)
trong PHP hoặc phần mở rộng BCmath.
Một số trường hợp sử dụng có khả năng vi phạm mặc dù chúng ta chưa đến năm 2038 là gì?
Vì vậy, một MySQL DATETIME có phạm vi 1000-9999, nhưng TIMESTAMP chỉ có phạm vi 1970-2038. Nếu hệ thống của bạn lưu trữ ngày sinh, ngày chuyển tiếp trong tương lai (ví dụ:thế chấp 30 năm) hoặc tương tự, bạn sẽ gặp phải lỗi này. Một lần nữa, không sử dụng TIMESTAMP nếu đây là sự cố.
Chúng tôi có thể làm gì với các ứng dụng hiện có sử dụng TIMESTAMP, để tránh cái gọi là sự cố, khi nó thực sự xảy ra?
Một số ứng dụng PHP sẽ vẫn còn tồn tại vào năm 2038, mặc dù khó có thể lường trước được vì web hầu như không phải là một nền tảng kế thừa.
Đây là quy trình thay đổi cột trong bảng cơ sở dữ liệu để chuyển đổi TIMESTAMP
đến DATETIME
. Nó bắt đầu với việc tạo một cột tạm thời:
# 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`
Tài nguyên