Bộ Chuyển Đổi Ngày ISO

Chuyển ISO 8601 sang Unix epoch, RFC 3339, SQL DATETIME, ngày theo tuần và ngày thứ tự với 4 múi giờ đồng thời, thời gian tương đối, serial Excel/Julian.

Thời gian tương đối
Thông tin ngày

    Về Bộ Chuyển Đổi Ngày ISO 8601

    Định dạng ngày và giờ là nghĩa địa của các chuẩn không tương thích: ISO 8601 (dạng cơ bản và mở rộng), RFC 2822, RFC 3339, SQL DATETIME, Unix epoch theo giây / mili-giây / micro-giây / nano-giây, serial Excel, Số Ngày Julian, ngày theo tuần ISO, ngày thứ tự ISO — và mỗi hệ thống xử lý múi giờ và giây nhuận theo cách riêng. Bộ chuyển đổi này nhận gần như mọi thứ (dán vào, công cụ tự nhận diện), rồi xuất mọi định dạng phổ biến đồng thời, cùng với bốn múi giờ tự chọn, ngày trong năm, số tuần ISO, quý, cờ năm nhuận và chuỗi thời gian tương đối ('3 giờ trước', 'sau 2 ngày').

    Không gọi mạng, không cookie, không log — chỉ là phép tính trong trình duyệt dựa trên cơ sở IANA của máy bạn. Hoàn hảo cho debug log, kiểm thử hợp đồng API, lập lịch xuyên đội nhóm và xuất sang bảng tính.

    Khác biệt thực tế giữa ISO 8601 'cơ bản' và 'mở rộng' là gì?

    Định dạng mở rộng (loại hằng ngày) dùng dấu phân cách: 2026-05-17T14:30:00.000Z. Cơ bản loại bỏ chúng: 20260517T143000Z. Cùng thông tin; dạng cơ bản được thiết kế cho hệ thống bộ ký tự hạn chế (mainframe, mã vạch, tên file Windows cấm dấu hai chấm). Hệ sinh thái API hiện đại ưu tiên mở rộng vì dễ đọc, nhưng cơ bản vẫn xuất hiện trong logging công nghiệp, timecode SMPTE phát sóng và firmware nhúng. RFC 3339 (profile thân thiện HTTP của ISO 8601) cấm cơ bản và yêu cầu mở rộng với 'T' hoặc ' ' làm dấu phân cách giờ và 'Z' hoặc '+HH:MM' làm múi giờ — vì vậy đa số REST API dùng 2026-05-17T14:30:00Z.

    Công cụ tự nhận diện số là giây, mili-giây, micro-giây hay nano-giây bằng cách nào?

    Theo cấp độ lớn. Unix epoch theo giây là số 10-11 chữ số cho bất kỳ ngày nào trong đời (1e9 ≈ 2001, 5e9 ≈ 2128). Mili-giây thêm 3 số 0 (1e12 ≈ 2001 ms). Micro-giây thêm 3 nữa (vùng 1e15). Nano-giây thêm 3 nữa (vùng 1e18). Parser kiểm tra: abs(n) < 1e11 → giây; < 1e14 → ms; < 1e17 → µs; ngược lại → ns. Không nhập nhằng cho ngày trong khoảng ~1970 đến 5000 sau Công Nguyên. Trường hợp biên: '0' đơn được hiểu là giây (1970-01-01 UTC). Số 13 chữ số luôn là mili-giây. Nếu có epoch độ chính xác giây từ 2086 trở đi (>11 chữ số), thêm chú thích — nhưng đó không phải vấn đề 2026.

    Tại sao thời gian tương đối nói 'sau 2 ngày' cho ngày rõ ràng chỉ còn 47 giờ?

    Thời gian tương đối làm tròn về đơn vị nguyên gần nhất — 47 giờ tròn lên 2 ngày vì đơn vị lớn hơn (ngày) gần ngưỡng sạch hơn. Logic ngưỡng: dưới 60 giây → 'vừa xong' hoặc 'X giây'; dưới 1 giờ → 'X phút'; dưới 1 ngày → 'X giờ'; dưới 30 ngày → 'X ngày'; dưới 1 năm → 'X tháng'; ngược lại 'X năm'. Khớp với quy ước Intl.RelativeTimeFormat dùng bởi trình duyệt, thông báo OS và đa số app nhắn tin. Cho phép tính chính xác (ví dụ 'còn bao nhiêu phút đến cuộc họp 15h'), hãy dùng đầu ra epoch giây và trừ.

    Ngày theo tuần ISO là gì và khi nào dùng?

    Ngày theo tuần ISO biểu diễn ngày dưới dạng 'năm-tuần-thứ' (vd 2026-W21-3 = Thứ Tư của tuần 21 năm 2026). Hai điểm lạ: (1) tuần ISO bắt đầu từ Thứ Hai (không phải Chủ Nhật như Mỹ); (2) tuần 1 chứa Thứ Năm đầu tiên trong năm — nghĩa là 1-3 tháng 1 có thể thuộc tuần 52 hoặc 53 của năm ISO trước. Dùng cho: hệ thống bảng lương/chấm công (tổng hợp tuần), hoạch định bán lẻ (52 tuần ổn định/năm), lịch phát sóng, lập sprint coi tuần là đơn vị nguyên tử và biểu đồ ICU hiển thị 'ngày từ khi nhập viện'. Tránh cho giao tiếp người ('đặt cuộc họp vào tuần 21' vô nghĩa nếu không có lịch tham chiếu).

    Bộ Chuyển Đổi Ngày ISO — Chuyển ISO 8601 sang Unix epoch, RFC 3339, SQL DATETIME, ngày theo tuần và ngày thứ tự với 4 múi giờ đồng thời, thời gia
    Bộ Chuyển Đổi Ngày ISO

    Bốn cột múi giờ có đồng bộ về cùng một khoảnh khắc không?

    Có — cả bốn cột hiển thị cùng một khoảnh khắc UTC (bất cứ gì đầu vào parse ra), chỉ biểu diễn ở các múi IANA khác nhau. Nếu nhập 2026-05-17T12:00:00Z, bạn thấy 12:00 ở UTC, 05:00 Los Angeles (UTC-7 DST), 08:00 New York (UTC-4 DST) và 19:00 ở TP.HCM (UTC+7). Intl.DateTimeFormat của trình duyệt xử lý chuyển DST, offset nửa giờ và 45 phút (Ấn Độ UTC+5:30, Nepal UTC+5:45) và thay đổi quy tắc múi giờ lịch sử qua tzdata IANA tích hợp. Hữu ích cho lịch xuyên đội, đối chiếu log đa vùng, và kiểm tra backend ghi chuỗi UTC kết Z thay vì vô tình ghi giờ địa phương.

    Tại sao serial Excel không khớp với cái Excel hiển thị trên máy tôi?

    Excel dùng hai hệ ngày và đa số người không biết. Mặc định ('hệ 1900'): ngày 1 = 1900-01-01, với bug nổi tiếng là Excel coi 1900 là năm nhuận (thực tế không) — thêm ngày 60 ma 1900-02-29 chưa từng tồn tại. Mac di sản ('hệ 1904'): ngày 1 = 1904-01-01. Bộ chuyển đổi này xuất theo hệ Windows 1900 (mặc định cho workbook mới) nhưng bù bug nhuận bằng cách neo ở 1899-12-30, mẹo mà chính Excel dùng nội bộ để cho phép toán đúng từ 1900-03-01 trở đi. Nếu bạn làm workbook Mac-1904, trừ 1462 khỏi serial của chúng tôi. Để kiểm tra workbook dùng hệ nào: File → Options → Advanced → 'Use 1904 date system'.

    Số Ngày Julian dùng để làm gì và tại sao là số thập phân?

    Số Ngày Julian (JDN) là số đếm liên tục các ngày kể từ trưa UTC ngày 1 tháng 1 năm 4713 trước Công Nguyên (epoch Julian proleptic do các nhà thiên văn chọn năm 1583 vì nó có trước mọi ghi chép lịch sử còn lại). Phần thập phân là phần ngày sau trưa UTC: .0 = trưa, .5 = nửa đêm. JDN chiếm ưu thế trong thiên văn, cơ học quỹ đạo vệ tinh, và phép tính ngày lịch sử vì bỏ qua các cải cách lịch (Julian → Gregorian 1582, có nước không áp dụng đến thế kỷ 20). JDN hôm nay khoảng 2.460.829. Modified Julian Day (MJD) là JDN − 2.400.000,5, ngắn hơn và dùng trong telemetry không gian và chuẩn CCSDS. Nếu không ở thiên văn hay hàng không vũ trụ, có lẽ bạn không cần — nhưng dân bảng tính dùng cho trừ ngày sạch (số ngày = JDN_b − JDN_a).

    Công cụ xử lý giây nhuận và ngày trước 1970 thế nào?

    Giây nhuận: không xử lý. Cả Unix epoch và đối tượng Date của JavaScript đều bỏ qua giây nhuận — mỗi ngày UTC chính xác 86.400 giây. UTC thực đã thêm 27 giây nhuận từ 1972, vì vậy về kỹ thuật có lệch ~27 giây giữa UTC hiển thị và thời gian nguyên tử 'thực'. Quan trọng cho: GPS, timestamp thị trường tài chính (sau MiFID II), đo lường khoa học độ chính xác cao. Không quan trọng cho: log, timestamp API, lập lịch, mọi thứ hướng người. Với ngày trước 1970, công cụ vẫn xử lý — giá trị epoch âm, ngày như 1066-10-14 (Trận Hastings) và ngày trước Công Nguyên hoạt động qua Date, dù phần mở rộng Gregorian proleptic nghĩa là ngày hiển thị có thể không khớp lịch Julian khi đó. Cho công việc lịch chính xác lịch sử, dùng thư viện thiên văn chuyên dụng.