Chuyển đổi timestamp
Chuyển timestamp Unix thành ngày dễ đọc - và ngược lại. Bạn nhận được giây, mili giây, ISO 8601, UTC, giờ địa phương, thứ trong tuần, chuỗi RFC 2822 và thời
Chuyển đổi giữa timestamp Unix và ngày dễ đọc, theo cả hai chiều và với cả giây lẫn mili giây. Dán 1735689600 hoặc 2026-01-01T00:00:00Z để xem giá trị tương đương theo UTC, theo múi giờ địa phương của bạn và ở những định dạng phổ biến như ISO 8601 và RFC 2822.
Việc này diễn ra liên tục khi đọc nhật ký, gỡ lỗi một API trả về số giây epoch, hoặc kiểm tra xem thời hạn của token có đúng như bạn nghĩ không. Phép chuyển đổi chính xác và chạy cục bộ, đồng thời công cụ cảnh báo khi một giá trị có vẻ đang ở đơn vị mili giây thay vì giây.
Cách chuyển đổi timestamp Unix
Dán một timestamp hoặc một ngày
Đọc giá trị đã chuyển đổi theo UTC và giờ địa phương
Sao chép định dạng bạn cần
Câu hỏi thường gặp
Giây hay mili giây?
Mười chữ số thường là giây, mười ba chữ số thường là mili giây. Công cụ nhận diện đơn vị khả năng và cho bạn đổi lại nếu kết quả trông sai.
Epoch Unix là gì?
Là số giây kể từ 1 tháng 1 năm 1970 00:00:00 UTC, không tính giây nhuận. Đây là cách chuẩn để lưu một thời điểm.
Dùng múi giờ nào?
Cả hai đều được hiển thị: UTC và múi giờ địa phương của trình duyệt, để bạn so sánh điều máy chủ ghi trong nhật ký với điều bạn thấy trên đồng hồ.
Công cụ có xử lý ngày trước năm 1970 không?
Có, giá trị âm biểu thị ngày trước mốc epoch, và ngày ở tương lai xa vẫn hoạt động trong giới hạn phạm vi ngày của JavaScript.
Công cụ có tạo được timestamp cho một ngày không?
Có, phép chuyển đổi chạy theo cả hai chiều - nhập một ngày và nhận giá trị epoch.
Có gì bị tải lên không?
Không, đây chỉ là phép tính cục bộ.
Tổng quan nhanh
| Đầu vào | văn bản |
|---|---|
| Nhiều tệp cùng lúc | Không |
| Chạy ở đâu | Ngay trong trình duyệt - tệp không bao giờ bị tải lên |
| Dùng được ngoại tuyến | Có — sau khi trang đã tải xong |
| Giá | Miễn phí, không đăng ký, không hình mờ |
Những chỗ việc chuyển đổi âm thầm hỏng
Phần lớn lỗi chuyển đổi không nằm ở cú pháp mà ở ý nghĩa. Một cột mã bưu chính trong CSV mất các số 0 đứng đầu ngay khi bảng tính đoán rằng đó là số; một ID dài vượt quá độ chính xác của số dấu phẩy động; ngày tháng đổi nghĩa tuỳ theo nó được viết theo kiểu ngày trước hay tháng trước. Các khoá JSON không có thứ tự nhưng mảng thì có, và một công cụ sắp xếp khoá thì không đổi gì, còn công cụ sắp xếp mảng thì đổi dữ liệu. Unicode là một cái bẫy khác: văn bản có thể đến dưới dạng UTF-8, UTF-16 hoặc kèm dấu thứ tự byte, và một bộ giải mã đoán sai sẽ biến các ký tự có dấu thành chữ hỏng. Trước khi tin vào bất kỳ phép chuyển đổi nào, hãy kiểm tra nhanh hàng đầu và hàng cuối, mọi trường có số 0 đứng đầu, và mọi trường chứa dấu ngoặc kép, dấu phẩy hay ký tự xuống dòng.
Chọn một định dạng dữ liệu
JSON là mặc định cho mọi thứ một API trả về hoặc một chương trình đọc vào: nó xử lý cấu trúc lồng nhau, số, giá trị boolean và null một cách tự nhiên, và ngôn ngữ nào cũng phân tích được nó. CSV nhỏ hơn và mở thẳng vào bảng tính, nhưng nó không có cách nào diễn tả cấu trúc lồng nhau và không có tiêu chuẩn chung cho ký tự phân tách, cách đặt ngoặc kép hay bộ ký tự - đó chính là chỗ các phép chuyển đổi hay sai. XML dài dòng nhưng mang được thuộc tính, nội dung hỗn hợp và lược đồ, nên nó vẫn chiếm ưu thế trong các định dạng tài liệu và những hệ thống tích hợp cũ. YAML dễ đọc nhất cho phần cấu hình nhưng rất nhạy với dấu cách và có những cách ép kiểu gây bất ngờ ("no" thành false, một phiên bản như 1.10 thành 1.1). Hãy chọn định dạng mà công cụ tiếp nhận ưa dùng, chứ không phải định dạng trông đẹp nhất.