Hướng dẫn định dạng ngày giờ, số và tiền tệ trong tiếng Việt

Ngày rà soát: 04/10/2026

Trả lời nhanh

Định dạng dữ liệu tiếng Việt bằng thư viện hỗ trợ locale, đồng thời giữ dữ liệu gốc tách khỏi chuỗi hiển thị. Cần chọn rõ ngôn ngữ, múi giờ, loại tiền và độ chính xác theo nhiệm vụ thực tế. Giao diện tiếng Việt không có nghĩa mọi giao dịch đều dùng VND hoặc mọi thời điểm đều hiển thị theo múi giờ thiết bị.

Những điểm cần nhớ

• Chọn tùy chọn định dạng rõ ràng thay vì phụ thuộc mặc định trình duyệt.
• Phân biệt ngày trên lịch với một thời điểm cụ thể.
• Lưu số tiền cùng loại tiền trong suốt luồng xử lý.
• Không đọc số bằng cách xóa dấu chấm, dấu phẩy một cách tùy tiện.
• Kiểm tra làm tròn, số âm, dữ liệu trống và màn hình hẹp.
• Ghi phiên bản môi trường chạy để có thể tái tạo ví dụ.

Locale quyết định điều gì và không quyết định điều gì?

Locale xác định ngôn ngữ và các tùy chọn vùng mà phần mềm dùng khi trình bày dữ liệu. Unicode CLDR công bố dữ liệu locale, trong đó có quy ước định dạng ngày và số tiếng Việt [1]. Tuy nhiên, locale không xác định một trường là ngày hóa đơn, giờ hẹn, số dư hay phần trăm thay đổi. Ý nghĩa nghiệp vụ vẫn cần được quy định riêng.

Một bảng điều khiển có thể dùng nhãn tiếng Việt, hóa đơn USD và múi giờ báo cáo do doanh nghiệp lựa chọn. Không nên gom cả ba thành một lựa chọn “chế độ Việt Nam”. Ghi riêng locale hiển thị, loại tiền giao dịch, múi giờ nghiệp vụ và độ chính xác.

Không định dạng bằng cách thay ký tự hàng loạt. Đổi mọi dấu chấm thành dấu phẩy có thể làm hỏng dấu phân nhóm, số thập phân hoặc mã định danh. Hãy bắt đầu từ dữ liệu có kiểu rõ ràng rồi đưa kết quả định dạng vào câu đã được rà soát.

Kết quả vi-VN và en-US khác nhau thế nào trong thử nghiệm?

Bảng dưới là kết quả được tạo khi biên soạn bài, không phải cam kết mọi trình duyệt luôn xuất cùng chuỗi. Môi trường thử là Node.js 24.18.0, ICU 78.3 và CLDR 48.0. Ví dụ ngày giờ dùng thời điểm 2026-10-04T08:05:00Z và múi giờ Asia/Ho_Chi_Minh.

Chuỗi tiền tệ thực tế có thể chứa khoảng trắng do bộ định dạng tạo ra. Khi so sánh chuỗi, đừng mặc định ký tự nhìn giống khoảng trắng luôn là dấu cách bàn phím. Nếu hệ thống cần kết quả chính xác từng ký tự, kiểm tra mã ký tự và môi trường chạy.

Trong thông báo hạn thanh toán, có thể ưu tiên năm đủ bốn chữ số dù kiểu short dùng hai chữ số. Đây là đề xuất về khả năng đọc, không phải thay đổi giá trị ngày. Lựa chọn cần phục vụ nhiệm vụ của người dùng.

Ngày và thời điểm nên được xử lý khác nhau ra sao?

Xác định dữ liệu là ngày trên lịch hay thời điểm. Ngày sinh và một số ngày nghiệp vụ không có ý nghĩa giờ trong ngày. Lịch hẹn hoặc sự kiện nhật ký lại cần được hiển thị trong múi giờ phù hợp. Không tự biến mọi ngày thành nửa đêm UTC rồi kỳ vọng mọi người đều thấy cùng ngày.

Với thời điểm, chọn rõ múi giờ hiển thị. API quốc tế hóa JavaScript có các tùy chọn định dạng ngày giờ, bao gồm timeZone [2]. Ví dụ sau minh họa dữ liệu thử cố định; nó không phải bộ đọc ngày nhập từ người dùng và không quyết định múi giờ của sản phẩm.

const instant = new Date('2026-10-04T08:05:00Z');
const formatter = new Intl.DateTimeFormat('vi-VN', {
  day: '2-digit',
  month: '2-digit',
  year: 'numeric',
  hour: '2-digit',
  minute: '2-digit',
  hourCycle: 'h23',
  timeZone: 'Asia/Ho_Chi_Minh'
});
console.log(formatter.format(instant));

Với đặt lịch hoặc hẹn hỗ trợ, nêu múi giờ khi cần. Người làm việc từ xa có thể dùng thiết bị đặt múi giờ khác. Một ảnh đúng trên máy lập trình viên chưa đủ chứng minh giờ hẹn dễ hiểu cho mọi khách hàng.

Tránh ngày số mơ hồ trong nội dung dùng qua nhiều thị trường. “04/10” có thể được hiểu khác nhau. Có thể dùng tên tháng hoặc nhãn giải thích rõ. Khi trao đổi với API, dùng định dạng mà API yêu cầu thay vì gửi chuỗi đã bản địa hóa như một giá trị máy có thể luôn hiểu.

Số thập phân và phần trăm cần quy định gì?

Chọn độ chính xác theo ý nghĩa. Số lượng tồn kho, đại lượng đo, chi phí dự kiến và tỷ giá có thể cần quy tắc khác nhau. API định dạng số cung cấp tùy chọn nhưng không chọn thay yêu cầu nghiệp vụ [2]. Đừng để mặc định làm tròn bỏ thông tin cần thiết.

Phần trăm dễ gây lỗi dữ liệu. Ví dụ dùng 0.125 để hiển thị 12,5%. Nếu dịch vụ lưu 12.5 với ý nghĩa phần trăm mà đưa thẳng vào cùng bộ định dạng, kết quả sẽ mang ý nghĩa khác. Cần ghi rõ dữ liệu lưu là tỷ lệ hay con số phần trăm.

Phân biệt phần trăm với điểm phần trăm. Khi tỷ lệ tăng từ 10% lên 12%, nhãn “tăng 2” chưa đủ. Người dịch cần biết công thức mà bảng điều khiển biểu diễn, nhất là khi có biểu tượng mũi tên hoặc nhãn rất ngắn.

Kiểm tra số âm, số không và giá trị gần ranh giới làm tròn. Số âm có thể là nợ, lỗ hoặc hoàn trả; màu sắc không nên là lời giải thích duy nhất. Một số rất nhỏ bị hiển thị thành không có thể gây hiểu sai nếu nó ảnh hưởng tới thao tác được phép.

Tiền tệ, khoảng giá trị và đơn vị đo nên được trình bày thế nào?

Tiền cần đi cùng loại tiền. Đổi ngôn ngữ không được tự đổi tiền giao dịch; đổi ký hiệu không phải là quy đổi tiền. Nếu có chuyển đổi, cần nguồn tỷ giá, thời điểm, cách làm tròn và phân biệt ước tính với khoản thực trả.

const amount = 1250.50;
const money = new Intl.NumberFormat('vi-VN', {
  style: 'currency',
  currency: 'USD',
  currencyDisplay: 'code'
});
console.log(money.format(amount));

Đoạn mã chỉ định dạng số tiền có sẵn, không xử lý thanh toán. Tích hợp thực tế vẫn phải xác thực loại tiền và độ chính xác theo hệ thống thanh toán. Không dùng chuỗi hiển thị làm bản ghi tài chính duy nhất.

Khoảng “5–10” cần đơn vị và ngữ cảnh. Năm đến mười ngày làm việc khác ngày theo lịch. Bộ lọc cần xác định có bao gồm hai đầu khoảng không. Đưa những hành vi đó vào yêu cầu để người dịch không phải đoán.

Với số đo, giữ đơn vị gắn với giá trị. Dịch tên đơn vị không tự chuyển kilogram sang pound. Nếu hỗ trợ chuyển đổi, kiểm tra cả số và đơn vị sau chuyển đổi. Tránh viết tắt không giải thích khi khách cần nhập đúng đại lượng.

Vì sao hiển thị và đọc dữ liệu nhập cần tách riêng?

Định dạng biến dữ liệu có kiểu thành chuỗi hiển thị. Đọc dữ liệu nhập là diễn giải chuỗi theo quy tắc đã công bố. Không thể mặc định hai quá trình tự đảo ngược nhau. Văn bản sao chép từ hóa đơn có thể chứa ký hiệu tiền và dấu phân nhóm mà biểu mẫu không chấp nhận.

Ví dụ “1.234” có thể bị diễn giải thành số nguyên hoặc số thập phân. Với tiền, khác biệt đó rất đáng kể. Hãy nói rõ định dạng nhập, cung cấp ví dụ và kiểm tra ở cả trình duyệt lẫn máy chủ thay vì đoán theo dấu câu.

Nếu cho nhập theo locale, định nghĩa những trường hợp hỗ trợ và kiểm thử. Nếu chỉ nhận số thập phân không phân nhóm, hướng dẫn rõ. Lỗi nên cho khách biết cách sửa và giữ lại nội dung nhập để họ chỉnh.

Tệp xuất cũng có yêu cầu riêng. Số tiền trong PDF dễ đọc và số trong tệp dữ liệu phục vụ hệ thống khác không nhất thiết dùng cùng chuỗi. Kiểm tra cách hệ thống nhận xử lý dấu phân cách, dấu thập phân và trường loại tiền.

Checklist QA nào giúp tái tạo kết quả kiểm tra?

Tạo bộ dữ liệu thử theo loại dữ liệu thật của sản phẩm. Lưu locale, tùy chọn, múi giờ và phiên bản môi trường cùng kết quả mong đợi. Kiểm tra lại khi cập nhật runtime hoặc dữ liệu locale.

Kiểm tra ảnh màn hình cùng kiểm tra dữ liệu. Giá trị đúng vẫn có thể bị cắt trong cột hẹp. Dùng số tiền lớn, số âm, đơn vị dài và ngày dạng dài. Khi đổi locale, xem cả tooltip, tải xuống và xác nhận.

Khuyến nghị thực hành của LocalizeZone

Lập đặc tả định dạng trước khi dịch màn hình nhiều dữ liệu. Mỗi trường nên ghi ý nghĩa, kiểu lưu, locale, loại tiền hoặc đơn vị, độ chính xác, múi giờ, trạng thái trống và cách nhập. Nhờ đó, các bất đồng được xử lý trước khi trở thành lỗi sử dụng.

Với bản địa hóa website, cung cấp ảnh và dữ liệu đại diện thay vì chỉ gửi nhãn. Rà soát cùng nhiệm vụ ở hai ngôn ngữ, gồm lỗi biểu mẫu, xác nhận và tệp xuất. Thay đổi triển khai cần được thống nhất với đội phụ trách mã nguồn.

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

Mọi ngày tiếng Việt phải hiển thị cùng một kiểu không?

Không. Bảng gọn, giấy tờ và xác nhận đặt lịch có thể cần độ chi tiết khác nhau. Chọn kiểu theo nhiệm vụ và kiểm tra khả năng nhầm lẫn.

vi-VN tự chọn đúng loại tiền không?

Không. Ứng dụng cần lưu và truyền loại tiền giao dịch. Locale đổi cách trình bày, không đổi ý nghĩa kinh tế.

Có thể đọc số tiếng Việt bằng cách xóa dấu chấm không?

Không nên áp dụng cho đầu vào chưa được quy định. Hãy định nghĩa định dạng chấp nhận và kiểm tra quy tắc đọc dữ liệu.

Vì sao kết quả có khoảng trắng khác thường?

Bộ định dạng có thể tạo ký tự khoảng trắng với hành vi trình bày riêng. Kiểm tra mã ký tự khi so sánh hoặc trao đổi dữ liệu.

Luôn dùng múi giờ trình duyệt có được không?

Không. Chọn múi giờ phù hợp nghiệp vụ và giải thích khi cần. Ngày trên lịch phải được xử lý riêng với thời điểm.

Mọi môi trường đều tạo đúng chuỗi trong bảng không?

Không nhất thiết. Bảng ghi kết quả của một môi trường đã thử. Cần chạy lại trên phiên bản mà sản phẩm thực tế hỗ trợ.

Nguồn và phương pháp

Tài liệu được kiểm tra ngày 04/10/2026. Bảng so sánh được tạo cục bộ từ dữ liệu JavaScript cố định bằng Node.js 24.18.0, ICU 78.3, CLDR 48.0. Trang ECMA-402 được đọc như tài liệu cập nhật liên tục, không phải bằng chứng mọi tính năng dự thảo đều đã triển khai. Cảnh báo nhập liệu, bảng QA và checklist bàn giao là khuyến nghị thực hành; không hàm ý số liệu thị trường hoặc khả năng của nhà cung cấp thanh toán.

Tài liệu tham khảo

1. Unicode CLDR — Locale Data Summary for Vietnamese, bảng phiên bản 48 — Unicode Consortium.
2. ECMA-402 — ECMAScript Internationalization API Specification, DateTimeFormat và NumberFormat — Ecma International / TC39, tài liệu cập nhật liên tục được truy cập khi rà soát.

Bài viết liên quan

• Cẩm nang bản địa hóa tiếng Việt cho phần mềm và SaaS
• Hướng dẫn UX Writing tiếng Việt cho nút bấm, biểu mẫu và thông báo lỗi
• Hướng dẫn bản địa hóa JSON: Chuỗi, biến và lỗi thường gặp
• Định dạng địa chỉ Việt Nam cho biểu mẫu, thương mại điện tử và cơ sở dữ liệu
• Tên người Việt: Hướng dẫn cho biểu mẫu, cơ sở dữ liệu và giao diện
• Định dạng số điện thoại Việt Nam cho website và ứng dụng