Cách chuyển đổi giữa các định dạng thời gian

· 9 phút đọc

Các định dạng thời gian khác nhau giữa các hệ thống, API và quốc gia. Dấu thời gian Unix trong các phản hồi API, ISO 8601 trong cơ sở dữ liệu, đồng hồ 12 giờ ở Hoa Kỳ, 24 giờ ở châu Âu, chuyển đổi là một nhu cầu liên tục đối với các nhà phát triển và bất kỳ ai làm việc với dữ liệu quốc tế.

Các định dạng thời gian phổ biến

Định dạng Ví dụ Được sử dụng bởi
Dấu thời gian Unix (giây) 1712502600 API, cơ sở dữ liệu, mã thông báo JWT
Dấu thời gian Unix (ms) 1712502600000 JavaScript, Java
ISO 8601 2026-04-07T14:30:00Z API JSON, cơ sở dữ liệu, nhật ký
RFC 2822 Mon, 07 Apr 2026 14:30:00 +0000 Tiêu đề email, HTTP
24 giờ 14:30 Châu Âu, quân đội, hàng không
12 giờ 2:30 PM Hoa Kỳ, sử dụng hàng ngày

Bảng ghi nhớ chuyển đổi nhanh

12 giờ sang 24 giờ

12 giờ 24 giờ
12:00 AM (nửa đêm) 00:00
1:00 AM 01:00
12:00 PM (giữa trưa) 12:00
1:00 PM 13:00
6:00 PM 18:00
11:59 PM 23:59

Dấu thời gian sang ngày

Sử dụng trình chuyển đổi epoch để dịch tức thì một dấu thời gian Unix sang ngày dễ đọc và ngược lại. Trình chuyển đổi tự động xử lý các định dạng theo giây và mili giây.

Mẹo

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

Định dạng ISO 8601 là gì?

ISO 8601 là tiêu chuẩn quốc tế để biểu diễn ngày và giờ. Nó trông giống như 2026-04-07T14:30:00Z, trong đó T phân tách ngày và giờ, và Z chỉ UTC. Nó không mơ hồ bất kể ngôn ngữ địa phương.

Tại sao các API sử dụng dấu thời gian Unix thay vì các ngày dễ đọc?

Dấu thời gian Unix là một số duy nhất, dễ lưu trữ, sắp xếp và so sánh. Chúng trung lập với múi giờ (luôn là UTC) và chiếm ít không gian hơn một chuỗi ngày được định dạng. Đánh đổi: chúng không thể đọc được bởi con người.

Z ở cuối dấu thời gian có nghĩa là gì?

Z có nghĩa là « Zulu time », một tên khác cho UTC (Coordinated Universal Time). Một dấu thời gian kết thúc bằng Z là ở UTC, không phải giờ địa phương.

Làm thế nào để chuyển giờ 24 giờ sang 12 giờ?

Đối với các giờ 1-12, giờ giữ nguyên (thêm AM cho 0-11, PM cho 12). Đối với 13-23, trừ 12 và thêm PM. 00:00 trở thành 12:00 AM (nửa đêm). 12:00 trở thành 12:00 PM (giữa trưa).

What is the Year 2038 problem?

32-bit signed Unix timestamps overflow on 19 January 2038 at 03:14:07 UTC, after which they wrap around to negative values that look like dates in 1901. Most modern systems use 64-bit timestamps and are unaffected, but legacy embedded devices, old databases, and 32-bit time_t in some C code still need to be audited.

How are leap seconds handled in Unix time?

Unix time pretends leap seconds do not exist. The clock simply repeats or stretches the affected second, so a Unix timestamp is not a strict count of elapsed SI seconds. For most applications this is fine, but precision-timing code (astronomy, GPS, high-frequency trading) needs TAI or UTC with explicit leap-second handling.