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

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

Bộ chuyển đổi timestamp này thuần hóa cả một nghĩa địa của các chuẩn ngày giờ 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. Xem thêm Tạo lịch và Máy tính ngày làm việc.

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.

Làm sao chuyển timestamp Unix thành ngày dễ đọc (và ngược lại)?

Để đi từ epoch sang ngày: dán timestamp Unix vào ô chính 'Nhập ngày'. Công cụ tự nhận diện đơn vị theo độ lớn (giây, mili-giây, micro-giây hoặc nano-giây) và lập tức hiển thị ISO 8601 mở rộng, RFC 3339, SQL DATETIME và giờ dễ đọc ở cả bốn cột múi giờ — nên 1747490400 trở thành 2025-05-17T14:00:00Z. Để đi ngược lại (ngày → epoch): dán bất kỳ ngày hoặc chuỗi ISO 8601 nào vào cùng ô đó và đọc các hàng 'Unix epoch (giây)' và 'Unix epoch (mili-giây)' trong bảng Epoch & serial; mỗi giá trị nằm trong hộp mã bấm để chọn, sao chép một chạm. Vì giây và mili-giây chênh nhau 1000 lần, hãy luôn xác nhận API hoặc cột cơ sở dữ liệu của bạn cần loại nào (to_timestamp() của PostgreSQL và đa số fromtimestamp() dùng giây; Date của JavaScript và Instant.ofEpochMilli() của Java dùng mili-giây).

Làm sao tính chính xác khoảng thời gian giữa hai ngày hoặc timestamp?

Đặt khoảnh khắc đầu vào ô 'Nhập ngày' và khoảnh khắc thứ hai vào ô 'So sánh với' (để trống để đo so với thời điểm hiện tại). Thẻ Khoảng thời gian chính xác sẽ hiển thị chênh lệch có dấu, chính xác theo hai cách: (1) chi tiết lịch theo năm, tháng, ngày, giờ, phút, giây tính bằng độ dài tháng thực — không phải xấp xỉ 30 ngày — nên tháng Hai và năm nhuận được xử lý đúng; và (2) các giá trị tổng theo ngày, giờ, phút, giây và mili-giây, mỗi giá trị trong hộp mã có thể sao chép. Đây chính là thứ bạn cần cho cửa sổ vi phạm SLA, khoảng cách giữa sự kiện log, uptime, kỳ thanh toán, khoảng bảng lương và tính 'thời gian đến hạn chót', không cần trừ epoch thủ công. Cả hai ô đều nhận mọi định dạng công cụ hiểu (ISO 8601, Unix epoch, RFC 2822/3339, SQL DATETIME), nên bạn thậm chí có thể tính khoảng cách giữa một giá trị epoch-giây và một ngày gõ tay.

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

Chuỗi thời gian tương đối cắt cụt (làm tròn xuống) về đơn vị nguyên lớn nhất — không bao giờ làm tròn lên. 47 giờ cắt thành '1 ngày', không phải 2, vì chúng tôi lấy Math.floor(47 / 24) = 1 và bỏ 23 giờ còn lại. Logic ngưỡng: dưới 60 giây → 'vừa xong' hoặc 'X giây'; dưới 1 giờ → cắt thành 'X phút'; dưới 1 ngày → cắt thành 'X giờ'; dưới 30 ngày → cắt thành 'X ngày'; dưới 1 năm → cắt thành 'X tháng'; ngược lại cắt thành 'X năm'. Cách cắt cụt có chủ đích này mô phỏng cách log và công cụ CLI hiển thị tuổi ('1d trước'), nhưng nó mất mát thông tin theo thiết kế. Để có câu trả lời chính xác, rõ ràng, hãy điền ô 'So sánh với' (hoặc để trống để so với hiện tại): thẻ Khoảng thời gian chính xác hiển thị chi tiết lịch đầy đủ (vd '1 ngày 23g 00p 00s') cùng các tổng số có thể sao chép theo ngày, giờ, phút, giây và mili-giây — không cần trừ thủ công.

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ố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.