Chuyển đổi Timezone

IANA timezone database

Mọi tên timezone bạn thấy trong tool này — America/New_York, Europe/Paris, Asia/Ho_Chi_Minh — đều đến từ IANA Time Zone Database, còn gọi là Olson database theo tên người bảo trì gốc Arthur David Olson. Database được publish tại https://www.iana.org/time-zones và được cập nhật nhiều lần mỗi năm khi các chính phủ thay đổi quy tắc timezone.

Database này làm nhiều hơn chỉ liệt kê UTC offset. Nó mã hóa toàn bộ lịch sử của quy tắc từng timezone: khi nào DST transition xảy ra, offset thay đổi như thế nào do quyết định chính trị, và khi nào các quốc gia áp dụng hoặc bỏ daylight saving time. Đây là lý do tại sao Asia/Ho_Chi_Minh biết rằng Việt Nam đã dùng UTC+8 trước năm 1975 và UTC+7 kể từ đó, và có thể convert chính xác timestamp từ bất kỳ thời điểm nào.

Tool này dùng date-fns-tz và API Intl.DateTimeFormat tích hợp sẵn của trình duyệt, cả hai đều lấy dữ liệu timezone từ IANA database đi kèm với hệ điều hành hoặc JavaScript runtime.

Tại sao dùng "America/New_York" thay vì "EST"

Viết tắt EST là "Eastern Standard Time" — UTC−5. Nhưng nó mơ hồ: EST cũng được dùng cho Australian Eastern Standard Time (UTC+10). Quan trọng hơn, EST không nói gì về daylight saving time. Khi New York đang dùng EDT (Eastern Daylight Time, UTC−4) vào mùa hè, dùng EST cho bạn offset sai.

IANA identifier America/New_York không có sự mơ hồ như vậy. Nó đề cập đến một vùng địa lý có quy tắc offset được chỉ định đầy đủ trong Olson database. Hệ thống tự động biết liệu thời điểm đó có rơi vào EST hay EDT. Luôn dùng IANA identifier trong code; dùng abbreviation chỉ để hiển thị.

Nguyên tắc tương tự áp dụng cho GMT vs UTC. GMT là một timezone (tại Royal Observatory ở Greenwich) và kỹ thuật mà nói thì có British Summer Time vào mùa hè. UTC là một time standard, không phải timezone — nó không bao giờ thay đổi, không có DST, và là baseline đúng đắn để lưu trữ timestamp.

DST transition

DST tạo ra hai thời điểm nổi tiếng khó xử lý mỗi năm:

Spring forward. Lúc 2:00 SA giờ địa phương, đồng hồ tiến đến 3:00 SA. Giờ từ 2:00 đến 3:00 không tồn tại. Một cuộc họp được lên lịch lúc 2:30 SA vào ngày đó là mơ hồ — không có khoảnh khắc wall-clock nào như vậy tồn tại. Hầu hết hệ thống bỏ qua giờ bị thiếu một cách im lặng.

Fall back. Lúc 2:00 SA giờ địa phương, đồng hồ quay lại 1:00 SA. Giờ từ 1:00 đến 2:00 xảy ra hai lần. Timestamp "1:30 SA" vào ngày đó là mơ hồ — có thể là lần đầu hoặc lần thứ hai. Thư viện date-fns-tz giải quyết vấn đề này bằng cách dùng offset trước transition cho lần xuất hiện đầu tiên.

Khi convert thời gian rơi vào hoặc gần DST transition, tool này chỉ ra liệu thời gian đích có mơ hồ không và hiển thị cả hai UTC equivalent có thể có khi áp dụng.

UTC vs giờ địa phương: quy tắc quan trọng nhất

Luôn lưu timestamp theo UTC. Đây là quy tắc có tác động lớn nhất trong xử lý thời gian. Giờ địa phương lưu trong database không có ý nghĩa gì nếu thiếu timezone, và quy tắc timezone thay đổi — timestamp lưu dưới dạng "09:00 ICT" trở nên sai nếu Việt Nam đổi quy tắc DST hoặc nếu server chuyển sang vùng khác.

Trong thực tế:

• Lưu TIMESTAMPTZ (hoặc tương đương) trong PostgreSQL, tự động convert sang UTC khi insert.
• Trong JavaScript, object Date lưu UTC millisecond nội bộ — dùng toISOString() để serialize (2026-05-26T14:30:00.000Z).
• Trong Python, dùng datetime.now(timezone.utc) không phải datetime.now() — dạng naive (không có tzinfo) là bẫy.
• Hiển thị theo giờ địa phương chỉ ở UI layer, không bao giờ trong business logic hay storage.

Các lỗi developer thường gặp

Lưu giờ địa phương không có timezone context. Cột datetime chứa 2026-03-08 02:30:00 trong ứng dụng US-based là dữ liệu corrupt — giờ địa phương đó không tồn tại (đã bị DST bỏ qua). Lưu UTC; convert khi hiển thị.

Nhầm lẫn "+00:00" với "Z". Cả hai đều có nghĩa UTC, nhưng Z (Zulu time) là chỉ định ISO 8601 nghiêm ngặt cho UTC. +00:00 là offset bằng không giờ — cùng giá trị số nhưng ngữ nghĩa khác. Ưu tiên Z cho UTC timestamp.

Dùng fixed-offset timezone trong code. new Date().toLocaleString('en-US', {timeZone: 'UTC+7'}) sẽ fail hoặc hoạt động sai trong nhiều môi trường. Luôn dùng IANA name (Asia/Ho_Chi_Minh cho giờ Việt Nam).

Giả định DST transition xảy ra vào nửa đêm. Ở Mỹ, switch xảy ra lúc 2:00 SA. Ở EU, lúc 1:00 SA UTC. Đừng bao giờ hardcode thời gian transition.

Arithmetic trên local timestamp. Cộng 24 giờ vào local timestamp qua ranh giới DST cho kết quả sai — một ngày có thể dài 23 hoặc 25 giờ thực. Thực hiện arithmetic theo UTC, sau đó convert sang giờ địa phương để hiển thị.

Dùng tool để lên lịch xuyên timezone

Một use case phổ biến: lên lịch meeting hoặc deployment window phù hợp cho team ở nhiều timezone. Nhập thời gian đề xuất và timezone địa phương của bạn, thêm các timezone của đồng đội, và tool hiển thị giờ địa phương tương ứng cho từng người. Kết hợp với Cron Parser tool (hiển thị next run theo UTC), bạn có thể xác minh rằng scheduled job kích hoạt vào giờ hợp lý ở mọi vùng quan trọng.

Quyền riêng tư

Tất cả conversion chạy trong trình duyệt của bạn bằng date-fns-tz và API Intl.DateTimeFormat. Không có timestamp hay timezone query nào được gửi đến server.

Công cụ liên quan

• Cron Parser — dịch cron expression thành next-run timestamp và hiểu timing UTC của chúng.
• Timestamp Converter — convert Unix epoch integer sang và từ ngày đọc được theo bất kỳ timezone nào.

IANA timezone database là gì và tại sao nó quan trọng?

IANA Time Zone Database (còn gọi là Olson database) là nguồn thẩm quyền cho quy tắc timezone trên toàn thế giới. Nó mã hóa không chỉ UTC offset hiện tại mà còn toàn bộ lịch sử của mỗi timezone — mọi thay đổi quy tắc DST, mọi quyết định chính trị về việc dịch chuyển đồng hồ. Không có nó, việc convert timestamp từ năm 1985 ở Asia/Ho_Chi_Minh (đã thay đổi offset nhiều lần) sẽ chỉ là đoán mò. Tất cả hệ điều hành, trình duyệt, và date library lớn đều đi kèm bản sao của database này.

Tại sao nên dùng Asia/Ho_Chi_Minh thay vì ICT?

ICT (Indochina Time) có thể đề cập đến Vietnam, Thailand, Laos, hay Cambodia — tất cả đều UTC+7 nhưng có lịch sử timezone khác nhau. Quan trọng hơn, abbreviation không nói gì về việc offset có thể thay đổi không. IANA identifier Asia/Ho_Chi_Minh mã hóa đầy đủ lịch sử offset, cho phép hệ thống convert chính xác bất kỳ timestamp lịch sử nào mà không cần bạn tra cứu thủ công.

Sự khác biệt giữa UTC và GMT là gì?

UTC (Coordinated Universal Time) là time standard được duy trì bằng atomic clock và không có daylight saving time. GMT (Greenwich Mean Time) là timezone tại Royal Observatory ở Greenwich, kỹ thuật mà nói có British Summer Time vào mùa hè. Trong thực tế chúng được coi là tương đương, nhưng kỹ thuật mà nói UTC là baseline đúng cho timestamp. Dùng UTC trong code; GMT chấp nhận được trong chuỗi hiển thị cho người dùng.

Điều gì xảy ra với cuộc hẹn 2:30 SA trong quá trình US spring-forward?

Giờ địa phương đó không tồn tại — lúc 2:00 SA, đồng hồ Mỹ nhảy đến 3:00 SA, vì vậy 2:30 SA không bao giờ xảy ra. Nếu hệ thống lưu timestamp đó như giờ địa phương mà không có UTC equivalent, thời gian là dữ liệu không hợp lệ. Hầu hết ứng dụng calendar và scheduling lưu UTC equivalent tại thời điểm cuộc hẹn được tạo, nên DST transition không làm hỏng entry hiện có.

Tại sao cộng 24 giờ vào ngày đôi khi cho kết quả sai?

Vào ngày DST transition, một ngày lịch dài 23 hoặc 25 giờ. Cộng 24 * 60 * 60 * 1000 millisecond vào local timestamp sẽ vượt qua số ngày lịch khác với mong đợi. Cách đúng là thêm một ngày lịch bằng hàm addDays của date library (xử lý DST), hoặc thực hiện arithmetic theo UTC và convert lại sang giờ địa phương để hiển thị.

Z ở cuối timestamp có nghĩa gì?

Z là viết tắt của "Zulu time" — ký hiệu quân sự cho UTC. Trong format ISO 8601, 2026-05-26T14:30:00Z nghĩa là 2:30 CH UTC. Nó tương đương với 2026-05-26T14:30:00+00:00, dù Z là dạng ưu tiên cho UTC timestamp vì rõ ràng và ngắn gọn hơn. Luôn bao gồm Z hoặc explicit offset khi serialize timestamp; 2026-05-26T14:30:00 không có zone indicator là naive datetime và là nguồn bug.

Làm thế nào để convert Unix timestamp sang datetime có timezone?

Unix timestamp luôn là số giây (hoặc millisecond) kể từ Unix epoch — 1970-01-01T00:00:00Z — theo UTC. Để hiển thị theo timezone địa phương, tạo object Date từ nó và format bằng Intl.DateTimeFormat chỉ định option timeZone, hoặc dùng hàm format của date-fns-tz. Ví dụ: format(new Date(epochMs), 'yyyy-MM-dd HH:mm:ss', { timeZone: 'Asia/Ho_Chi_Minh' }). Giá trị epoch tự nó không phụ thuộc timezone.

Tool có xử lý đúng các thay đổi timezone lịch sử không?

Có, trong giới hạn của phiên bản IANA database được đi kèm với JavaScript runtime của trình duyệt. Database bao phủ các transition lịch sử từ cuối thế kỷ 19 cho hầu hết các vùng. Với ngày rất cũ (trước 1970), dữ liệu có thể thưa hoặc không chắc chắn, nhưng với mọi timestamp thực tế hiện đại (sau 1970), các conversion là thẩm quyền. Nếu IANA data của trình duyệt lỗi thời, quy tắc timezone thay đổi gần đây có thể không phản ánh đúng — hiếm gặp, thường chỉ xảy ra trên hệ điều hành cũ.