Trình Chuyển Đổi Dấu Thời Gian Unix Miễn Phí
Chuyển đổi giữa dấu thời gian Unix và ngày dễ đọc.
Dấu thời gian → Ngày
Ngày → Dấu thời gian
Dấu thời gian Unix là gì?
Dấu thời gian Unix (còn gọi là thời gian epoch hoặc thời gian POSIX) là số giây đã trôi qua kể từ ngày 1 tháng 1 năm 1970, 00:00:00 UTC. Đây là một cách đơn giản, không phụ thuộc vào múi giờ để biểu diễn một thời điểm và được sử dụng rộng rãi trong lập trình, cơ sở dữ liệu, API và nhật ký máy chủ.
Ví dụ, dấu thời gian 1700000000 biểu thị ngày 14 tháng 11 năm 2023 lúc 22:13:20 UTC. JavaScript sử dụng dấu thời gian mili giây (nhân với 1000), trong khi hầu hết các ngôn ngữ và API khác sử dụng giây.
Câu hỏi thường gặp
Tôi có thể nhập những định dạng ngày nào?
Bạn có thể nhập ngày ở hầu hết các định dạng chuẩn: ISO 8601 (2025-12-31T23:59:59Z), chuỗi ngày thông thường (Dec 31, 2025 11:59 PM) hoặc các định dạng đơn giản như 2025-12-31 23:59:59. Trình chuyển đổi sử dụng trình phân tích ngày tích hợp của trình duyệt.
Nó có tự động phát hiện giây so với mili giây không?
Có. Nếu dấu thời gian lớn hơn 1 nghìn tỷ, trình chuyển đổi sẽ coi đó là mili giây. Nếu không, nó sẽ coi đó là giây. Cả hai định dạng đều được hiển thị trong bảng kết quả.
Vấn đề Năm 2038 là gì?
Các hệ thống lưu trữ dấu thời gian Unix dưới dạng số nguyên có dấu 32 bit sẽ bị tràn vào ngày 19 tháng 1 năm 2038 lúc 03:14:07 UTC. Các hệ thống hiện đại sử dụng số nguyên 64 bit, có thể biểu diễn ngày trong hàng tỷ năm tới. Công cụ này sử dụng kiểu Number của JavaScript, xử lý tốt các dấu thời gian vượt xa năm 2038.
Tại sao là ngày 1 tháng 1 năm 1970?
Một timestamp Unix là một số nguyên đếm số giây đã trôi qua kể từ kỷ nguyên Unix, 00:00:00 UTC vào thứ Năm, ngày 1 tháng 1 năm 1970. Đây là một số đơn nhất xác định duy nhất một khoảnh khắc trong thời gian, không phụ thuộc vào lịch hay múi giờ, cùng một con số đặt tên cho cùng một khoảnh khắc dù bạn ở Tokyo hay Toronto.
Việc chọn năm 1970 phần nào tùy ý, nhưng không ngẫu nhiên. Phiên bản đầu tiên của UNIX Programmer's Manual (tháng 11 năm 1971) định nghĩa thời gian hệ thống là số tick xung nhịp 60 Hz kể từ ngày 1 tháng 1 năm 1971. Với một số nguyên không dấu 32-bit đếm ở 60 Hz, hệ thống sẽ chỉ kéo dài khoảng 2,26 năm trước khi tràn, một vấn đề trở nên rõ ràng nhanh chóng. Khi phiên bản thứ hai được chuẩn bị vào năm 1972, đội của Ken Thompson và Dennis Ritchie chuyển sang đếm giây kể từ ngày 1 tháng 1 năm 1970: số nguyên có dấu 32-bit đếm giây sẽ kéo dài khoảng 68 năm, vượt xa thời gian làm việc của các kỹ sư viết mã, và Tết Dương lịch gần nhất trước khi dự án bắt đầu làm cho phép tính số học dễ dàng. Không có cuộc bỏ phiếu của ủy ban và không có quy trình tiêu chuẩn hóa kiểu IANA. Sự lựa chọn đã được giữ lại vì Unix được phát hành cùng với nó, và một khi một trăm triệu máy đếm từ khoảnh khắc đó, không có sự thay thế nào khả thi.
POSIX (1988) đã hệ thống hóa kỷ nguyên 1970 với tên "Seconds Since the Epoch" của IEEE Std 1003.1. Ngày nay, cùng một kỷ nguyên đó là nền tảng cho time_t của C/C++, time.time() của Python, Time.now.to_i của Ruby, JavaScript và Java (tính bằng mili giây, xem bên dưới), timestamp file system của Linux/macOS, các header khối Bitcoin và Ethereum, và các claim iat/exp/nbf của JWT. Một số hệ thống sử dụng kỷ nguyên offset (FILETIME của Windows đếm tick 100 nano giây kể từ ngày 1 tháng 1 năm 1601, DateTime của .NET đếm tick kể từ ngày 1 tháng 1 năm 0001), nhưng thời gian Unix là ngôn ngữ chung cho mọi thứ vượt qua ranh giới HĐH hoặc ngôn ngữ.
Giây vs mili giây, lỗi phổ biến nhất
POSIX định nghĩa timestamp là giây kể từ kỷ nguyên. Mọi thư viện C, mọi interpreter Python, mọi runtime Ruby/Go/Rust/Elixir đều trả về giây. JavaScript là ngoại lệ nổi tiếng, Date.now() và new Date().getTime() trả về mili giây. System.currentTimeMillis() của Java tuân theo cùng quy ước, và một số hệ thống database mới hơn (kiểu Date của MongoDB BSON, chẳng hạn) cũng lưu trữ mili giây.
Kết quả là một lỗi xuyên ngôn ngữ vĩnh viễn: một backend Go viết 1700000000 (giây) vào một trường JSON; một client Node.js chuyển nó vào new Date(1700000000), nhưng JavaScript mong đợi mili giây, vì vậy ngày kết quả là 1970-01-20 thay vì cuối năm 2023. Cách sửa là new Date(1700000000 * 1000). Ngược lại, gửi một timestamp mili giây JS đến datetime.fromtimestamp() của Python tạo ra năm ~55895. Stack Overflow có hàng chục biến thể của câu hỏi "JavaScript Date hiển thị 1970", và sự không khớp là nguyên nhân gốc rễ trong đại đa số.
Bộ chuyển đổi này thực hiện một heuristic: nếu đầu vào lớn hơn 1.000.000.000.000, hãy xử lý như mili giây; nếu không, hãy xử lý như giây. Điều này hoạt động vì 1e12 giây sẽ là năm 33658 SCN (vượt xa bất kỳ đầu vào quy mô giây thực tế nào), trong khi 1e12 mili giây là ngày 9 tháng 9 năm 2001 UTC (trong phạm vi hiện đại). Timestamp micro giây và nano giây được sử dụng trong một số hệ thống khoa học và API kernel Linux sẽ đẩy ngưỡng lên cao hơn, với những cái đó, bạn sẽ cần chỉ định độ chính xác một cách rõ ràng.
Vấn đề Năm 2038 ("Y2K38")
Một số nguyên có dấu 32-bit có thể lưu trữ các giá trị từ −2.147.483.648 đến +2.147.483.647. Được hiểu là giây kể từ ngày 1 tháng 1 năm 1970 UTC, khoảnh khắc tối đa có thể biểu diễn là 03:14:07 UTC vào thứ Ba, ngày 19 tháng 1 năm 2038. Một giây sau đó, bộ đếm tràn và bao quanh đến giá trị âm nhất, được giải mã là 20:45:52 UTC vào thứ Sáu, ngày 13 tháng 12 năm 1901. Bất kỳ time_t nào rộng 32-bit, bất kỳ cột database nào lưu trữ một số nguyên có dấu 4 byte cho thời gian, và bất kỳ hệ thống embedded nào có firmware được viết trước khoảng năm 2010 đều có nguy cơ.
Bề mặt phơi nhiễm khó chịu: PLC công nghiệp và bộ điều khiển SCADA với chu kỳ triển khai 15-30 năm được lắp đặt ngày nay; các cột TIMESTAMP MySQL cũ hơn được tài liệu hóa bão hòa tại ranh giới 2038; file system ext3; các định dạng giao thức nhị phân (trường RRSIG DNSSEC, NTPv3, một số fieldbus công nghiệp) đóng gói một timestamp 4 byte; smart TV và infotainment ô tô chạy âm thầm các kernel Linux 32-bit cũ hơn được cài đặt. Cách khắc phục chính là mở rộng time_t thành 64-bit, kéo dài tối đa lên khoảng +292 tỷ năm, vượt qua cái chết nhiệt của Mặt Trời. Linux 5.6 (tháng 3 năm 2020) đã thêm các syscall thời gian 64-bit vào tất cả các kiến trúc 32-bit thông qua patchset y2038 của Arnd Bergmann; glibc 2.34 (tháng 8 năm 2021) đã làm cho time_t 64-bit opt-in qua _TIME_BITS=64; Debian 13 "Trixie" (2025) là phiên bản đầu tiên với toàn bộ kho lưu trữ được biên dịch lại. Apple đã ngưng sử dụng các tệp nhị phân 32-bit trong macOS 10.15 (2019) và iOS 11 (2017), vì vậy đội ngũ người tiêu dùng thực sự miễn dịch.
Bề mặt rủi ro còn lại chủ yếu là embedded và dữ liệu cũ trên đĩa: một kernel 64-bit đọc một cột timestamp 32-bit từ một database cũ cũng bị hỏng như chính database đó. Di chuyển là một vấn đề định dạng dữ liệu theo từng ứng dụng, không chỉ là vấn đề kernel.
JavaScript Date, API bị nguyền rủa nhất trong lĩnh vực
Đối tượng Date của JavaScript được sao chép nguyên vẹn từ Java 1.0 vào tháng 5 năm 1995 trong cuộc chạy nước rút 10 ngày mà Brendan Eich đã dành để viết LiveScript ban đầu. Bản thân Java đã ngưng dùng hầu hết các phương thức của java.util.Date trong JDK 1.1 (1997), nhưng JavaScript thừa hưởng chúng và không thể phá vỡ tương thích với web, vì vậy chúng vẫn còn. Kết quả là một API mà:
- Tháng được lập chỉ mục từ 0 (
new Date(2024, 0, 15)= 15 tháng 1) nhưng ngày được lập chỉ mục từ 1. getYear()trả về "năm trừ 1900",getYear()cho 2024 là 124.getFullYear()được thêm sau để trả về 2024 trực tiếp.Date.parse('2024-03-15')được phân tích là nửa đêm UTC;Date.parse('2024/03/15')là nửa đêm địa phương;Date.parse('March 15, 2024')được định nghĩa bởi triển khai.- Trước ECMAScript 5 (tháng 12 năm 2009), việc phân tích cú pháp gần như hoàn toàn do triển khai định nghĩa, cùng một chuỗi đầu vào có thể tạo ra các giá trị
Datekhác nhau trên IE, Firefox, Chrome và Safari.
Temporal API (TC39 Stage 3 kể từ tháng 3 năm 2021) là sự thay thế hiện đại, cung cấp Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime và một kiểu Temporal.Duration thực sự. Hỗ trợ trình duyệt đang được triển khai (Firefox Nightly, Safari 18 một phần, Chrome đằng sau một cờ tính đến năm 2024); polyfill hoạt động nhưng thêm ~25 KB. Moment.js đã được những người duy trì đưa vào chế độ bảo trì vào tháng 9 năm 2020, đối với các dự án mới năm 2026, khuyến nghị là Temporal trước tiên nếu hỗ trợ trình duyệt cho phép, Luxon hoặc date-fns nếu không, và Moment.js không bao giờ.
Khi nào bạn sẽ dùng đến nó
- Gỡ lỗi phản hồi API. Hầu hết các API JSON trả về timestamp dưới dạng số nguyên Unix hoặc chuỗi ISO 8601, và nhiều API trộn chúng. Dán một con số vào bộ chuyển đổi hàng chục lần mỗi ngày là trường hợp sử dụng có khối lượng cao nhất.
- Phân tích file log. syslog, journald, AWS CloudWatch và hầu hết các nhật ký ứng dụng được đánh dấu thời gian theo giây Unix. Các kỹ sư sao chép một timestamp từ một dòng log và cần biết tương đương đồng hồ treo tường.
- Kiểm tra cột ngày database. Một truy vấn
psqlhoặcmysqlđơn lẻ trả về1700000000; database có các hàm nhưFROM_UNIXTIME()nhưng một công cụ trình duyệt nhanh hơn cho công việc ad-hoc. - Kiểm tra JWT. Giải mã một token OAuth hiển thị
"exp": 1738367200. Token này đã hết hạn chưa? Khi nào nó hết hạn? Bộ chuyển đổi timestamp là câu trả lời nhanh nhất. - Timestamp blockchain.
nTimekhối Bitcoin là giây Unix (tràn vào năm 2106, 4 byte không dấu). Timestamp khối Ethereum cũng là giây Unix. - Metadata file system của HĐH.
ls -l --time-style=+%sin mtime Unix;stat -c '%Y' filenametrả về mtime dưới dạng số nguyên. Việc đối chiếu timestamp pháp y thường liên quan đến giải mã thủ công. - Chứng chỉ
notBefore/notAftervà header HTTPIf-Modified-Since, tất cả timestamp đôi khi cần được giải mã.
Một ghi chú về giây nhuận
Kể từ năm 1972, 27 giây nhuận đã được chèn vào UTC để giữ thời gian đồng hồ treo tường phù hợp với vòng quay đang chậm lại của Trái Đất. Giây gần đây nhất là ngày 31 tháng 12 năm 2016 23:59:60 UTC. Thời gian Unix không mã hóa giây nhuận, POSIX nói rõ ràng rằng một timestamp Unix giả vờ mỗi ngày có chính xác 86.400 giây. Các hệ thống Linux cũ hơn "lặp lại" giây cuối cùng; Google và AWS sử dụng "leap smear" trải đều giây thêm trong cửa sổ 24 giờ. Dù bằng cách nào, thời gian Unix không bao giờ đọc 23:59:60 trong lưu trữ, và việc trừ hai timestamp bao gồm một giây nhuận tạo ra câu trả lời ngắn hơn một giây so với thời gian giây-SI thực sự đã trôi qua. Đối với mã ứng dụng, điều này là không nhìn thấy được. Đối với phần mềm thiên văn hoặc giao dịch tài chính, điều đó có thể quan trọng. Vào tháng 11 năm 2022, Hội nghị Tổng quát về Trọng lượng và Đo lường lần thứ 27 đã bỏ phiếu ngừng chèn giây nhuận vào năm 2035, thay thế chúng bằng một sự điều chỉnh định kỳ lớn hơn nhiều.
Tham khảo nhanh
| Timestamp | UTC datetime | Note |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The epoch |
| 1,000,000,000 | 2001-09-09 01:46:40 | First "billion-second" milestone |
| 1,234,567,890 | 2009-02-13 23:31:30 | "Cool number" celebrated by some devs |
| 1,700,000,000 | 2023-11-14 22:13:20 | |
| 2,000,000,000 | 2033-05-18 03:33:20 | "Two billionth second" |
| 2,147,483,647 | 2038-01-19 03:14:07 | Last second representable in signed 32-bit |
| 4,294,967,295 | 2106-02-07 06:28:15 | Last representable in unsigned 32-bit (Bitcoin's nTime limit) |
| 9,999,999,999 | 2286-11-20 17:46:39 | Last 10-digit timestamp |
Câu hỏi thêm
Tại sao cùng một timestamp lại hiển thị thời gian khác trên máy của bạn tôi?
Bởi vì con số cơ bản là UTC, nhưng hiển thị chuyển đổi sang thời gian địa phương. 1700000000 là 22:13:20 UTC, nhưng 17:13:20 ở New York và 06:13:20 ngày hôm sau ở Sydney. Con số là như nhau; chỉ có cách hiển thị khác nhau. Để loại trừ sự nhầm lẫn múi giờ, hãy yêu cầu cả hai máy hiển thị bằng UTC.
Sự khác biệt giữa Y2K và Y2K38 là gì?
Y2K (Năm 2000) là một vấn đề logic trong mã ứng dụng: nhiều hệ thống lưu trữ năm dưới dạng hai chữ số ASCII, vì vậy "00" trở nên không rõ ràng giữa 1900 và 2000. Mỗi ứng dụng phải được kiểm tra và vá riêng lẻ; tổng chi phí khắc phục trên toàn thế giới ước tính khoảng 300-600 tỷ đô la. Y2K38 chủ yếu là một vấn đề kiểu dữ liệu trong các thư viện cấp thấp, biên dịch lại thư viện C và kernel với time_t 64-bit khắc phục một phần lớn bề mặt cho mọi ứng dụng liên kết với chúng. Các trường hợp khó còn lại là dữ liệu được lưu trữ trên đĩa (database, metadata file, giao thức nhị phân) cần công cụ di chuyển dữ liệu. Trí tuệ thông thường cho rằng 2038 sẽ là một sự kiện nhỏ hơn, ít đáng đưa tin hơn so với 2000, nhiều lỗi thiết bị embedded cục bộ hơn, ít gián đoạn nổi bật hơn.
Tại sao new Date('2024-03-15') đôi khi hiển thị ngày 14 tháng 3?
Bởi vì chuỗi đó được phân tích là nửa đêm UTC theo tiêu chuẩn ES5, và sau đó được hiển thị trong múi giờ địa phương của bạn. Trong một múi giờ UTC-8 như Thái Bình Dương Hoa Kỳ, nửa đêm UTC vào ngày 15 tháng 3 là 16:00 ngày 14 tháng 3 giờ địa phương, vì vậy .getDate() trả về 14. Cách khắc phục trong mã hiện đại là hoặc new Date('2024-03-15T12:00:00') (mà JavaScript phân tích là buổi trưa địa phương khi bạn bỏ qua Z) hoặc, tốt hơn, API Temporal.PlainDate.from() khi nó được phát hành.
Có gì được gửi đến máy chủ không?
Không. Việc chuyển đổi là phép toán JavaScript chạy cục bộ trong trình duyệt của bạn. Không có gì về các timestamp bạn nhập rời khỏi trang, hữu ích khi các giá trị là ID khách hàng, dòng log nội bộ, hoặc dữ liệu gỡ lỗi phiên mà bạn không muốn tải lên bất kỳ đâu. Trang hoạt động ngoại tuyến sau khi được tải.
Công cụ liên quan
Công cụ Chuyển Đổi Đơn Vị Trực Tuyến Miễn Phí
Chuyển đổi ngay giữa độ dài, cân nặng, nhiệt độ, lưu trữ dữ liệu, tốc độ, thời gian và diện tích.
Công cụ Định Dạng & Xác Thực JSON Trực Tuyến Miễn Phí
Định dạng, thu gọn và xác thực JSON ngay lập tức. Dán JSON của bạn và nhận đầu ra được định dạng với thông báo lỗi. Miễn phí, không cần đăng ký, chạy trong trình duyệt của bạn.
Trình mã hóa & giải mã Base64 miễn phí trực tuyến
Mã hóa văn bản sang Base64 hoặc giải mã Base64 sang văn bản ngay lập tức. Hỗ trợ chuyển đổi tệp sang Base64. Miễn phí, không đăng ký, chạy trong trình duyệt của bạn.