Trình Tạo Dấu Thời Gian Unix

Cách hoạt động

1. Chuyển ngày sang timestamp: nhập ngày và giờ với bộ chọn, sau đó nhấp Tạo để có timestamp Unix theo giây và mili giây.
2. Chuyển timestamp sang ngày: dán một timestamp Unix (giây hoặc mili giây) để chuyển ngược thành ngày và giờ dễ đọc.
3. Lấy timestamp hiện tại: nhấp « Bây giờ » để lấy ngay timestamp Unix của thời điểm hiện tại.

Tại sao sử dụng trình tạo timestamp Unix?

Timestamp Unix là ngôn ngữ phổ quát của thời gian trong tin học, một số nguyên duy nhất đại diện cho số giây trôi qua kể từ ngày 1 tháng 1 năm 1970 (UTC). Chúng cung cấp năng lượng cho cơ sở dữ liệu, API, nhật ký, mã thông báo xác thực và lập lịch sự kiện. Chuyển đổi thủ công giữa timestamp và ngày dễ đọc liên quan đến tính toán múi giờ dễ bị sai. Công cụ này xử lý đúng việc chuyển đổi theo cả hai hướng, tiết kiệm thời gian và tránh các lỗi múi giờ.

Tính năng

• Chuyển đổi hai chiều: ngày/giờ → timestamp Unix và timestamp Unix → ngày/giờ.
• Giây và mili giây: hỗ trợ thời gian Unix theo giây (10 chữ số) cũng như mili giây (13 chữ số).
• Xử lý múi giờ: hiển thị giờ theo múi giờ cục bộ của bạn và theo UTC để so sánh không mơ hồ.
• Nút thời gian hiện tại: lấy ngay timestamp của thời điểm hiện tại.
• Hiển thị tương đối: chỉ ra cách đây bao lâu hoặc còn bao lâu (ví dụ « cách đây 3 ngày »).

Câu hỏi thường gặp

Timestamp Unix là gì?

Timestamp Unix là số giây trôi qua kể từ kỷ nguyên Unix, nửa đêm UTC ngày 1 tháng 1 năm 1970. Đó là biểu diễn của một thời điểm độc lập với múi giờ, làm cho nó là định dạng được ưa thích để lưu trữ và so sánh các thời điểm trong cơ sở dữ liệu và API.

Tại sao JavaScript sử dụng mili giây?

Date.now() và new Date().getTime() trong JavaScript trả về mili giây kể từ kỷ nguyên (một số 13 chữ số), trong khi các công cụ Unix và hầu hết cơ sở dữ liệu sử dụng giây (10 chữ số). Kiểm tra xem timestamp của bạn có 10 hay 13 chữ số để biết bạn có định dạng nào.

Làm thế nào để chuyển timestamp sang giờ địa phương?

Dán timestamp; công cụ tự động chuyển nó sang múi giờ cục bộ của trình duyệt của bạn. Hiển thị cho thấy cả giờ địa phương và UTC để làm việc giữa các múi giờ một cách tự tin.

Thời gian Unix đến từ đâu

Thời gian Unix được định nghĩa bởi Ken Thompson và Dennis Ritchie trong Unix First Edition (tháng 11 năm 1971). Ban đầu kernel đếm 1/60 giây kể từ 1971-01-01 trong trường 32 bit, tràn sau 2 năm 9 tháng. Đến Unix Sixth Edition (1975), cách đếm đã được đổi thành số giây kể từ 1970-01-01 00:00:00 UTC, kỷ nguyên mà mọi hệ thống giống Unix vẫn dùng ngày nay. Việc chọn lựa là tùy ý, các kỹ sư cần một ngày tròn gần với thời đại họ đang làm việc. POSIX.1 (1988) đã hệ thống hóa định nghĩa thành tiêu chuẩn chính thức, và POSIX.1-2017 (IEEE Std 1003.1-2017), phiên bản hiện tại, vẫn định nghĩa time_t là số giây kể từ kỷ nguyên, với cảnh báo rằng thời gian POSIX giả vờ giây nhuận không tồn tại. ISO 8601 (1988, hiện tại 2019) đã chuẩn hóa định dạng dễ đọc 2026-05-13T14:30:00Z, và RFC 3339 (tháng 7 năm 2002) đã thu hẹp nó thành hồ sơ ngày giờ internet rõ ràng. Date.now() của JavaScript trả về milisecond kể từ kỷ nguyên vì spec được viết vào năm 1995 khi độ chính xác dưới giây đã có nhu cầu; hầu hết các cơ sở dữ liệu và tiện ích Unix vẫn dùng giây nguyên.

Vấn đề năm 2038 (và tại sao quan trọng bây giờ)

time_t có dấu 32 bit có thể biểu diễn nhiều nhất 2.147.483.647 giây, đến vào 03:14:07 UTC Thứ Ba, 19 tháng 1 năm 2038. Một giây sau, bộ đếm cuộn về −2.147.483.648, mà hầu hết phần mềm hiểu là 13 tháng 12 năm 1901. Đây là cùng loại lỗi như Y2K nhưng do chiều rộng số nguyên, không phải định dạng ngày. Cách khắc phục là dùng time_t 64 bit (đẩy việc cuộn lại sang khoảng năm 292 tỷ). Hầu hết các hệ thống Linux 64 bit đã dùng time_t 64 bit theo mặc định; Linux 5.6 (tháng 3 năm 2020) đã làm cho time_t 64 bit cũng có sẵn trên kiến trúc 32 bit. Rủi ro còn lại sống trong các hệ thống nhúng, định dạng tệp nhị phân cũ và giao thức mạng 32 bit. Network Time Protocol (NTP) đã cuộn vào năm 2036 vì nó dùng đếm 32 bit không dấu kể từ năm 1900, NTPv4 thêm số kỷ nguyên để mở rộng nó. Nếu bạn cung cấp phần mềm xử lý ngày, hãy kiểm tra ngăn xếp của bạn trước năm 2038, đặc biệt là các cột SQL kiểu INT(11) hoặc mã C cũ với trường thời gian long.

Các định dạng timestamp bạn sẽ gặp

• Giây Unix (10 chữ số). 1747143000. time_t POSIX cổ điển. Được dùng bởi PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), TTL Redis, claim iat/exp JWT (theo RFC 7519), git log, và hầu hết các tiện ích Unix. Sẽ là 11 chữ số sau tháng 11 năm 2286.
• Mili giây Unix (13 chữ số). 1747143000000. Date.now() của JavaScript, System.currentTimeMillis() của Java, Kafka, Elasticsearch, và hầu hết các pipeline logging hiện đại. Nhân 1000 đếm giây.
• Micro giây Unix (16 chữ số) và nano giây (19 chữ số). 1747143000000000. Được dùng bởi time.time_ns() của Python, time.Now().UnixNano() của Go, các bản sửa đổi etcd MVCC, và các hệ thống giao dịch tần số cao nơi độ phân giải mili giây quá thô.
• ISO 8601. 2026-05-13T14:30:00.000Z hoặc 2026-05-13T14:30:00+02:00. Có thể sắp xếp như chuỗi, rõ ràng về múi giờ, được chấp nhận bởi hầu như mọi API hiện đại. Hậu tố Z có nghĩa là «thời gian Zulu», một ký hiệu của NATO cho UTC.
• RFC 3339. Một hồ sơ nghiêm ngặt hơn của ISO 8601 được dùng bởi JSON Schema, OpenAPI, và hầu hết các API REST. Yêu cầu một ký hiệu múi giờ và cấm một số tính năng ISO 8601 như ngày tuần và ngày thứ tự.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. Định dạng header email Date:. Vẫn ở khắp nơi vì SMTP chạy khắp mọi nơi.
• Ngày serial Excel. Ngày phân số kể từ 1900-01-01 (hoặc 1904 trên Excel Mac cổ điển). 2026-05-13 14:30 là khoảng 46150.6042. Excel nổi tiếng coi 1900 là năm nhuận (nó không phải) để tương thích với Lotus 1-2-3.

Khi công cụ này kiếm được công sức của mình

• Gỡ lỗi JWT. Token có "exp": 1747143000 và bạn cần biết liệu nó đã hết hạn chưa. Dán, xem ngày con người.
• Pháp y nhật ký. Một dòng nói timestamp=1747143012345, bạn cần tương quan với thời gian đồng hồ tường của công cụ khác. 13 chữ số, vậy là milisecond.
• Truy vấn cơ sở dữ liệu. Bạn muốn tìm các hàng sau ngày cụ thể. WHERE created_at > 1747143000 cần giá trị giây; sao chép nó từ công cụ.
• Fixture kiểm thử. Mã hóa cứng «hôm qua» trong một bài kiểm tra, bạn tạo timestamp ngay bây giờ và dán nó vào spec.
• Cron / công việc theo lịch. Xác minh giá trị giây mà bộ lập lịch sẽ kích hoạt, đặc biệt qua các chuyển đổi DST.
• Phát lại sự kiện. Offset Kafka và chỉ mục Elasticsearch thường dùng timestamp ms; chuyển sang ngày để kiểm tra một cửa sổ phát lại cụ thể.
• Vô hiệu hóa bộ nhớ cache. Header Expires hoặc If-Modified-Since ở định dạng RFC 2822, tạo định dạng wire chính xác để kiểm thử.

Lỗi tốn các nhóm hàng giờ

• Trộn giây và milisecond. Truyền giá trị 10 chữ số cho hàm mong đợi milisecond trả về ngày năm 1970, lệch bởi hệ số 1000. Quy tắc 10-vs-13 chữ số là phép kiểm thử nhanh nhất, giá trị hiện đại trong giây là 10 chữ số cho đến 2286, trong milisecond 13 chữ số.
• Lưu trữ thời gian địa phương. Luôn lưu UTC; chuyển sang địa phương vào thời gian hiển thị. Lưu "2026-05-13 14:30:00" không có múi giờ bị hỏng vào khoảnh khắc một máy chủ, người dùng, hoặc bước nhảy DST thay đổi offset địa phương.
• Quên các chuyển đổi DST. 2:30 sáng xảy ra hai lần trong khi lùi lại. Mã ngây thơ làm start + (24 * 3600) để nghĩa là «ngày mai» sẽ lệch một giờ hai lần một năm. Sử dụng thư viện ngày thực tế (luxon, date-fns-tz, zoneinfo Python) biết cơ sở dữ liệu IANA tz.
• Cho rằng thời gian POSIX tính giây nhuận. Nó không. 2016-12-31 23:59:60 tồn tại trong đời thực (giây nhuận thứ 27) nhưng time_t POSIX nhảy từ 23:59:59 đến 00:00:00 mà không nhận thức về giây phụ. TAI (Thời gian Nguyên tử Quốc tế) đếm giây nhuận, thời gian POSIX bù từ UTC bằng không giây.
• Lưu time_t trong cột INT(4). Các schema MySQL cũ thường dùng INT là 4 byte / có dấu 32 bit / cuộn vào năm 2038. Di chuyển sang BIGINT hoặc TIMESTAMP. Loại TIMESTAMP của các nhà cung cấp MySQL được lưu trữ cũng là 4 byte theo mặc định, hãy kiểm tra tài liệu.
• Phân tích cú pháp ISO 8601 bằng regex. Các triển khai nửa vời âm thầm bỏ múi giờ. Sử dụng trình phân tích cú pháp nền tảng: new Date(s) trong JavaScript, datetime.fromisoformat(s) trong Python ≥ 3.11, Instant.parse(s) trong Java.
• Excel tự động chuyển đổi timestamp. Dán 1747143012345 vào Excel mà không có tiền tố ' (một dấu nháy đơn nguyên văn) làm cho Excel đọc nó như một số, đôi khi chuyển sang ký hiệu khoa học. Hoặc định dạng cột là Văn bản trước, hoặc dán với tiền tố dấu nháy đơn.

Câu hỏi thường gặp khác

Tại sao 1970-01-01 được chọn làm kỷ nguyên?

Tiện lợi. Các phiên bản Unix sớm vào những năm 1970 muốn một kỷ nguyên không tràn trong tuổi thọ làm việc hợp lý. 1970-01-01 là một ngày tròn gần thời đại phát triển, và bộ đếm giây 32 bit từ đó đạt thoải mái đến 2038. Lựa chọn này hiện được khắc trong POSIX.1-2017 §4.16 và là một trong những thỏa thuận đa nền tảng ổn định nhất trong phần mềm. Không có ý nghĩa vốn có cho ngày, không có sự kiện lịch sử, không có neo thiên văn, chỉ là một neo tùy ý mà mọi người đều đồng ý.

Sự khác biệt giữa UTC, GMT và thời gian Zulu là gì?

Với mục đích phần mềm, chúng đề cập đến cùng thời gian đồng hồ tường. UTC (Thời gian Phối hợp Toàn cầu) là tiêu chuẩn hiện đại, được định nghĩa bởi đồng hồ nguyên tử và BIPM. GMT (Thời gian Trung bình Greenwich) là tiêu chuẩn thiên văn Anh cũ hơn là tham chiếu thế giới de facto trước thời gian nguyên tử. Thời gian Zulu là ký hiệu NATO/quân sự cho UTC, được viết như hậu tố Z trong ISO 8601 (2026-05-13T14:30:00Z). UTC và GMT có thể khác nhau lên đến 0,9 giây vì UTC được điều khiển để giữ gần UT1 (thời gian mặt trời trung bình) qua giây nhuận, nhưng không có ứng dụng nào không dùng trực tiếp UT1 sẽ nhận thấy.

Tại sao 1970 đôi khi được hiển thị khi tôi mong đợi điều gì khác?

Hai nguyên nhân phổ biến. Đầu tiên, timestamp ở milisecond nhưng được truyền cho một hàm mong đợi giây, hoặc ngược lại, cho một ngày lệch bởi hệ số 1000. Thứ hai, giá trị là 0 hoặc NaN, cả hai đều được hầu hết thư viện ngày kết xuất là 1970-01-01T00:00:00Z. Kiểm tra chiều rộng số nguyên thô: 10 chữ số là giây, 13 là milisecond, 16 là microsecond, 19 là nanosecond.

Công cụ này sẽ xử lý timestamp âm cho các ngày trước 1970 chứ?

Có. new Date(-86400000) trả về 1969-12-31T00:00:00Z. Date của JavaScript có thể đại diện cho bất kỳ khoảnh khắc nào từ −271821-04-20 đến +275760-09-13, tức là khoảng ±100 triệu ngày từ kỷ nguyên. Ngoài phạm vi đó, API trả về Invalid Date. Đối với các ngày lịch sử, cũng nhận thức về chuyển đổi Julian-Gregorian (1582 ở các nước Công giáo, 1752 ở Anh, muộn nhất là 1923 ở Hy Lạp) nơi các ngày lịch nhảy từ 10 đến 13 ngày; các thư viện ngày khác nhau về cách xử lý điều này.

Dữ liệu timestamp của tôi có được gửi đi đâu không?

Không. Tất cả việc chuyển đổi đều chạy bằng JavaScript bên trong trình duyệt của bạn. Trang không bao giờ POST bất kỳ giá trị nào bạn nhập. Mở tab Mạng trong DevTools và chuyển đổi một timestamp, bạn sẽ thấy không có yêu cầu đi ra trong khi chuyển đổi. An toàn cho token với claim timestamp, dòng log nội bộ, hoặc bất cứ thứ gì bạn sẽ không dán vào dịch vụ lưu trữ.