Unix timestamp là gì?

Con số được định nghĩa thế nào

POSIX định nghĩa "số giây kể từ epoch" bằng một công thức cố định: mỗi ngày được tính đúng 86.400 giây, và việc đếm bắt đầu từ 1970-01-01T00:00:00Z. Các thời điểm trước epoch mang giá trị âm, nên -1 là 1969-12-31T23:59:59Z.

Vì giá trị được đo theo UTC, nó không mang múi giờ cũng không có giờ mùa hè. Chuyển nó sang giờ địa phương là một bước riêng cần có múi giờ, ví dụ Asia/Tokyo hoặc America/New_York.

Giây, mili giây và các đơn vị khác

Unix timestamp kinh điển tính bằng giây, nhưng nhiều hệ thống lưu đơn vị nhỏ hơn. Với các ngày hiện tại, số chữ số là cách nhanh nhất để phân biệt:

Lẫn lộn đơn vị là lỗi timestamp phổ biến nhất. Truyền giá trị tính bằng giây vào new Date() của JavaScript sẽ ra một ngày trong tháng 1 năm 1970; đọc giá trị mili giây như giây sẽ ra một ngày cách hàng chục nghìn năm trong tương lai. Trong JavaScript, dùng Math.floor(Date.now() / 1000) để lấy giây, và new Date(seconds * 1000) để chuyển ngược lại.

Giây nhuận không được tính

Thỉnh thoảng UTC chèn thêm một giây nhuận để khớp với chuyển động quay của Trái Đất; từ năm 1972 đã có 27 giây nhuận được thêm vào. Unix time bỏ qua chúng: công thức POSIX giả định mỗi ngày có 86.400 giây, nên giây nhuận hoặc bị lặp lại, hoặc được dàn trải (smear) trong một khoảng thời gian dài hơn, tùy hệ thống.

Trên thực tế, điều này nghĩa là lấy hai timestamp trừ nhau sẽ ra khoảng thời gian có thể lệch đúng bằng số giây nhuận ở giữa. Với việc lên lịch hằng ngày, sai số này không đáng kể; với đo thời gian trong khoa học hay tài chính, các hệ thống dùng TAI hoặc giờ GPS. Năm 2022, các tổ chức đo lường thời gian quốc tế đã biểu quyết ngừng thêm giây nhuận chậm nhất vào năm 2035.

Sự cố năm 2038

Phần mềm cũ lưu Unix time trong số nguyên có dấu 32 bit, có giá trị tối đa là 2147483647. Giá trị đó đạt tới vào 2038-01-19T03:14:07Z. Một giây sau, bộ đếm bị tràn thành -2147483648, được đọc thành 1901-12-13T20:45:52Z.

• Hệ điều hành, ngôn ngữ lập trình và cơ sở dữ liệu 64 bit hiện đại dùng time_t 64 bit, đủ dùng trong khoảng 292 tỷ năm.
• Rủi ro vẫn còn ở thiết bị nhúng, định dạng file cũ, cột cơ sở dữ liệu 32 bit như TIMESTAMP của MySQL, và các giao thức nhị phân chỉ dành bốn byte cho thời gian.
• Các giá trị dài hạn như chứng chỉ 20 năm, khoản vay thế chấp và ngày hết hạn đã vượt qua năm 2038, nên lỗi có thể xuất hiện từ rất lâu trước thời điểm đó.

Khi nào dùng timestamp, khi nào dùng chuỗi ngày

Hãy lưu các thời điểm (khi một sự kiện xảy ra, khi token hết hạn) dưới dạng Unix timestamp hoặc chuỗi ngày UTC. Cả hai đều rõ ràng và sắp xếp đúng.

Dùng chuỗi ISO 8601 dễ đọc như 2026-10-14T09:30:00Z trong log, API và file mà con người sẽ đọc, vì nhìn qua thì 1791970200 chẳng nói lên điều gì. Với sự kiện địa phương trong tương lai, như cuộc họp lúc 09:00 ở Paris vào mùa xuân tới, hãy lưu giờ địa phương kèm tên múi giờ IANA: quy tắc giờ mùa hè có thể thay đổi trước ngày đó, và một timestamp tính sẵn khi ấy sẽ bị sai.