Unix Timestamp là gì?

Unix timestamp là một con số duy nhất: số giây đã trôi qua kể từ kỷ nguyên Unix, được định nghĩa là 00:00:00 UTC ngày 1 tháng 1 năm 1970. Chỉ có vậy. Không múi giờ, không chuỗi ngày tháng, không tên tháng — chỉ là một số nguyên tăng dần một đơn vị mỗi giây.

Vì kỷ nguyên này cố định và phổ quát, một timestamp như 1700000000 có nghĩa là cùng một thời điểm chính xác ở mọi nơi trên Trái Đất. Một máy chủ ở Tokyo và một máy tính xách tay ở Chicago đều sẽ đồng ý rằng nó chỉ thời điểm 14 tháng 11 năm 2023 lúc 22:13:20 UTC. Cách hiển thị địa phương khác nhau tùy theo múi giờ, nhưng con số cơ bản không bao giờ thay đổi.

Một sự đơn giản hóa có chủ đích: Unix time bỏ qua giây nhuận. Nó giả định mỗi ngày dài chính xác 86.400 giây, điều này không hoàn toàn đúng với thực tế thiên văn nhưng giữ cho các phép tính toán được sạch sẽ. Sẽ có thêm thông tin bên dưới.

Tại sao các Kỹ sư yêu thích chúng

Timestamp có mặt ở khắp mọi nơi trong phần mềm — thời gian sửa đổi tệp, bản ghi cơ sở dữ liệu, phản hồi API, trường hết hạn JWT, dòng log — và vì những lý do chính đáng:

• Chúng là một giá trị duy nhất. Một số nguyên lưu trữ đầy đủ ngày và giờ. Không cần phân tích cú pháp, không có sự mơ hồ về MM/DD so với DD/MM.
• Chúng không phụ thuộc vào múi giờ. Con số luôn là UTC. Bạn chỉ chuyển đổi sang giờ địa phương khi hiển thị cho con người.
• Chúng dễ dàng so sánh và sắp xếp. Sự kiện nào xảy ra trước? Số nguyên nhỏ hơn. Khoảng thời gian giữa hai sự kiện? Trừ chúng ra; kết quả là số giây.
• Chúng lưu trữ nhỏ gọn. Một số nguyên 4 hoặc 8 byte so với một chuỗi đã định dạng.

Đây là lý do tại sao rất nhiều cơ sở hạ tầng hoạt động ngầm bằng giây kỷ nguyên, ngay cả khi giao diện hiển thị cho bạn một 2026-07-23 thân thiện. Nếu bạn muốn chuyển đổi giữa hai cách biểu diễn này, một Công cụ chuyển đổi dấu thời gian Unix sẽ thực hiện việc dịch thuật theo cả hai chiều.

Đọc Một Timestamp: Ví dụ Cụ thể

Lấy timestamp 1000000000 — một cái nổi tiếng, vì nó đã vượt ngưỡng trên truyền hình trực tiếp giữa những người đam mê Unix.

Để đọc nó bằng tay, bạn chia số giây thành các đơn vị lớn hơn. Một cách gần đúng, 1.000.000.000 giây là khoảng 31,7 năm (một năm là ~31.556.952 giây). Cộng nó vào kỷ nguyên 1970 và bạn sẽ đến năm 2001. Thời điểm chính xác là 09 tháng 9 năm 2001, 01:46:40 UTC.

Bạn hiếm khi thực hiện phép tính số học này theo cách thủ công — mọi ngôn ngữ đều có hàm tích hợp sẵn. Trong Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

Điểm mấu chốt: việc chuyển đổi luôn được neo vào UTC. Hàm này biến một số giây thô thành một ngày dương lịch bằng cách tiến về phía trước từ kỷ nguyên. Nếu bạn muốn giờ địa phương thay thế, bạn áp dụng một độ lệch múi giờ sau khi chuyển đổi UTC — bản thân timestamp không mang thông tin múi giờ.

Vấn đề Năm 2038

Đây là lúc câu chuyện trở nên thú vị — và là nơi mà nhiều hệ thống được xây dựng tốt khác có một quả bom hẹn giờ bên trong chúng.

Trong nhiều thập kỷ, kiểu C tiêu chuẩn được sử dụng để lưu trữ Unix time, time_t, thường là một số nguyên có dấu 32 bit. Một số nguyên có dấu 32 bit có thể biểu diễn các giá trị từ −2.147.483.648 đến 2.147.483.647. Giới hạn trên đó chính là vấn đề.

Đếm số giây từ kỷ nguyên 1970, giá trị 2.147.483.647 đạt được vào lúc 03:14:07 UTC ngày 19 tháng 1 năm 2038. Một giây sau, bộ đếm cần trở thành 2.147.483.648 — nhưng con số đó không vừa trong một số nguyên có dấu 32 bit. Thay vì tiếp tục tăng lên, các bit bị tràn và quay vòng về giá trị âm nhất, −2.147.483.648.

Một timestamp âm được hiểu là thời điểm trước kỷ nguyên. Vì vậy, đồng hồ không chỉ dừng lại — nó nhảy ngược về ngày 13 tháng 12 năm 1901. Bất kỳ hệ thống nào tin tưởng vào time_t 32 bit của nó đột nhiên tin rằng nó đang ở đầu thế kỷ 20.

Điều này thường được gọi là lỗi Y2K38 hoặc Lỗi Thiên niên kỷ Unix, và về mặt cấu trúc, nó cũng là loại tràn số nguyên có độ rộng cố định đã gây ra nỗi sợ hãi Năm 2000 — chỉ là xa hơn một chút và bắt nguồn từ giới hạn số nguyên nhị phân thay vì năm có hai chữ số.

Nơi Nó Thực Sự Gây Hại

Các máy tính để bàn và máy chủ 64-bit hiện đại phần lớn đã được sửa từ nhiều năm trước. Rủi ro tập trung ở những nơi khó cập nhật:

• Hệ thống nhúng và công nghiệp. Bộ định tuyến, bộ điều khiển, thiết bị y tế, ECU ô tô và phần cứng IoT được xuất xưởng với time_t 32 bit và có thể hoạt động không bị can thiệp trong hơn 20 năm. Nhiều thiết bị được triển khai ngày hôm nay vẫn sẽ hoạt động vào năm 2038.
• Mã C kế thừa. Các ứng dụng được biên dịch dựa trên định nghĩa time_t cũ, đặc biệt là khi kiểu này len lỏi vào các định dạng lưu trữ trên đĩa hoặc giao thức mạng.
• Cơ sở dữ liệu và hệ thống tệp cũ. Các định dạng lưu trữ đã nhồi nhét timestamp vào các trường 32 bit. Một số hệ thống cũ hơn đã có dấu hiệu hoạt động sai khi xử lý các ngày trong tương lai xa — hãy nghĩ đến một khoản thế chấp 20 năm hoặc chứng chỉ hết hạn vượt quá năm 2038.

Chế độ hỏng hóc không phải lúc nào cũng là một sự cố nghiêm trọng. Đôi khi đó là một ngày tháng được tính toán sai một cách tinh vi: một token hết hạn được đọc là còn hiệu lực, một thứ tự sắp xếp bị đảo ngược, một công việc đã lên lịch được kích hoạt vào năm 1901.

Giải pháp: Thời gian 64 Bit

Biện pháp khắc phục về nguyên tắc là đơn giản — mở rộng time_t lên 64 bit. Một số nguyên có dấu 64 bit có thể đếm số giây vượt xa mọi chân trời thực tế: điểm tràn nằm ở khoảng 292 tỷ năm trong tương lai, thoải mái vượt quá tuổi thọ dự kiến của Mặt Trời.

Hầu hết các hệ điều hành hiện tại đã thực hiện bước đi này. Linux 64 bit sử dụng time_t 64 bit; ngay cả Linux 32 bit cũng đã có hỗ trợ thời gian 64 bit trong nhân và glibc trong những năm gần đây. Phần khó không phải là bản thân việc sửa chữa — mà là tìm kiếm và xây dựng lại từng mảnh firmware, từng định dạng lưu trữ và từng tệp nhị phân của bên thứ ba vẫn còn giả định 32 bit. Công việc kiểm toán đó mới là dự án thực sự cho năm 2038.

Giây Nhuận Phù Hợp Như Thế Nào

Thời gian thiên văn và thời gian nguyên tử lệch nhau một chút, vì vậy UTC chính thức thỉnh thoảng chèn một giây nhuận để giữ cho đồng hồ đồng bộ với vòng quay của Trái Đất. Unix time, theo thiết kế, giả vờ như chúng không tồn tại — nó mã hóa cứng 86.400 giây mỗi ngày.

Khi một giây nhuận xảy ra, các hệ thống thường "làm nhòe" nó — trải rộng giây thừa ra trong một khoảng thời gian (Google đã phổ biến phương pháp làm nhòe 24 giờ) để không có đồng hồ nào phải hiển thị giá trị bất khả thi 23:59:60. Kết quả là: các timestamp Unix vẫn mượt mà và đơn điệu, với cái giá là lệch một phần rất nhỏ của giây so với UTC nghiêm ngặt trong quá trình làm nhòe. Đối với hầu hết mọi phần mềm, đây chính xác là sự đánh đổi mà bạn muốn. Sự tràn số năm 2038 là một vấn đề về độ rộng số nguyên; giây nhuận là một đặc điểm kỳ quặc định nghĩa riêng biệt, nhỏ hơn nhiều — đừng nhầm lẫn chúng.

Những Điểm Chính

• Unix timestamp là số giây kể từ 00:00:00 UTC ngày 1 tháng 1 năm 1970, bỏ qua giây nhuận.
• Nó là một số nguyên duy nhất, không phụ thuộc vào múi giờ — dễ lưu trữ, so sánh và sắp xếp.
• Việc chuyển đổi luôn liên quan đến UTC; giờ địa phương được áp dụng sau đó.
• time_t 32 bit có dấu bị tràn vào lúc 03:14:07 UTC ngày 19 tháng 1 năm 2038, quay vòng thành giá trị âm và nhảy về năm 1901.
• Giải pháp là time_t 64 bit; nỗ lực là kiểm toán các hệ thống nhúng và kế thừa.

Muốn xem nó hoạt động? Dán bất kỳ giá trị kỷ nguyên nào vào Công cụ chuyển đổi dấu thời gian Unix để đọc nó dưới dạng ngày tháng cho con người — hoặc làm theo cách khác và biến một ngày tháng thành timestamp của nó.

Các Câu Hỏi Thường Gặp

Unix timestamp tính bằng giây hay mili giây?

Unix time cổ điển tính bằng giây. Tuy nhiên, JavaScript và nhiều API web sử dụng mili giây kể từ kỷ nguyên, vì vậy một giá trị như 1700000000000 lớn hơn 1.000 lần. Một dấu hiệu nhanh: timestamp dựa trên giây cho một ngày gần đây có 10 chữ số; timestamp mili giây có 13 chữ số. Khi nghi ngờ, hãy kiểm tra độ lớn trước khi chuyển đổi.

Vấn đề Năm 2038 có làm hỏng điện thoại hoặc máy tính xách tay của tôi không?

Gần như chắc chắn là không. Các hệ điều hành 64 bit hiện đại đã sử dụng time_t 64 bit, đẩy sự cố tràn ra xa hàng tỷ năm. Sự phơi nhiễm thực sự nằm ở các thiết bị nhúng tồn tại lâu dài và phần mềm cũ vẫn dựa vào thời gian 32 bit và có thể không được cập nhật trước năm 2038.

Unix timestamp có thể là số âm không?

Có. Các giá trị âm biểu diễn các thời điểm trước kỷ nguyên 1970 — ví dụ: -1 là 31 tháng 12 năm 1969, 23:59:59 UTC. Đây chính xác là những gì mà sự tràn số 32 bit tạo ra vào năm 2038, đó là lý do tại sao đồng hồ dường như nhảy ngược về năm 1901.

Tại sao Unix time bỏ qua giây nhuận?

Để giữ cho các phép toán đơn giản và có thể dự đoán được. Coi mỗi ngày là chính xác 86.400 giây có nghĩa là khoảng thời gian chỉ là phép trừ và các timestamp vẫn đơn điệu. Sự không khớp nhỏ với UTC thiên văn được xử lý bằng cách "làm nhòe" giây nhuận, điều mà hầu hết các ứng dụng đều thích hơn là phải đối phó với trường hợp ngoại lệ 23:59:60.

Làm cách nào để chuyển đổi timestamp mà không cần viết mã?

Sử dụng một công cụ trực tuyến. Công cụ chuyển đổi dấu thời gian Unix chấp nhận một giá trị kỷ nguyên và hiển thị ngay lập tức ngày giờ UTC và địa phương tương ứng, đồng thời nó cũng chuyển đổi ngày dương lịch trở lại thành timestamp.