Vì sao máy tính thường hiển thị mốc 1/1/1970 và lỗi năm 2038

Tóm tắt nhanh

• Mốc January 1, 1970 00:00 UTC là epoch của Unix time, tức điểm bắt đầu để các hệ thống Unix-like đếm số giây đã trôi qua. Đây không phải ngày đặc biệt, mà là mốc được chọn khi Unix cần một cách đơn giản để lưu thời gian.
• Unix time hiện được lưu bằng signed 32-bit integer, nên chỉ theo dõi được một phạm vi hữu hạn. Cách lưu này từng được chọn vì gọn và đủ dùng, nhưng nó cũng tạo ra giới hạn về sau.
• Khi hệ thống không đọc được thời gian hoặc nhận giá trị 0, nhiều máy sẽ mặc định quay về epoch. Vì vậy bạn có thể thấy 1970-01-01 trong spreadsheet, app, metadata file hoặc màn hình lỗi.
• Nếu múi giờ của bạn lùi sau UTC, giá trị mặc định có thể hiện thành cuối ngày 31/12/1969 thay vì đầu 1/1/1970. Điều này vẫn là cùng một mốc epoch, chỉ khác cách hiển thị theo múi giờ.
• Việc dùng 60Hz ở giai đoạn đầu từng được thử, nhưng lưu trong 32-bit integer khiến giá trị cạn chỗ sau chưa tới 2,5 năm. Sau đó Unix chuyển sang tính bằng giây để kéo dài giới hạn sử dụng.
• Vì signed integer dùng bit trái nhất để biểu thị số âm, nó chỉ còn một nửa dải giá trị so với unsigned integer. Đổi lại, hệ thống mới có thể biểu diễn cả thời điểm trước năm 1970.
• Giới hạn trên của Unix time là 2,147,483,647 giây kể từ epoch. Khi vượt qua mốc này, bit trái nhất đổi trạng thái và thời gian bị hiểu thành số âm.
• Theo bài viết, lỗi tràn này sẽ xảy ra vào January 19, 2038 lúc 3:14:07 AM UTC. Khi đó máy có thể hiển thị sai thành December 13, 1901 lúc 8:45:52 PM UTC.
• Đây là lý do sự cố được gọi là “year 2038 problem”. Bài viết cho biết vẫn còn thời gian để triển khai các biện pháp khắc phục trước khi mốc này đến.
• Unix time đã trở thành nền tảng cho nhiều hệ điều hành như Linux, macOS và Android, trong khi Windows là ngoại lệ chính. Việc đồng bộ theo UTC cũng giúp máy tính so sánh hai mốc thời gian dễ hơn.

Tóm tắt tự động bằng AI từ bài gốc, có thể có sai sót. Hãy kiểm chứng ở bài gốc.