Có một định dạng ngày phổ quát mà bất cứ ai trên thế giới có thể hiểu?


10

Ở Canada, mọi người đều quen thuộc với định dạng ngày YYYY-MM-DD. Ở châu Âu hoặc Nam Phi, họ thích DD-MM-YYYY. Có những người dùng từ Nam Phi bị nhầm lẫn với YYYY-MM-DDđịnh dạng ngày. Có cách nào để xử lý tình huống này?

Tôi đã nghĩ đến việc sử dụng định dạng phương thức sau cho tất cả: Feb 02, 2011


21
Tôi nghĩ rằng định dạng YYYY-MM-DD cũng là một tiêu chuẩn ISO.
Thất vọngWithFormsDesigner

2
"Ở châu Âu hoặc Nam Phi, họ thích DD-MM-YYYY." Ngoại trừ ví dụ ở Hungary ( YYYY.MM.DD) hoặc Phần Lan ( DD.MM.YYYY) hoặc ... Xin lỗi, thực tế rất lộn xộn :-(
Péter Török

6
Những lịch khác nhau thì sao?

4
Khi thu thập dữ liệu radar (ở Bắc Mỹ), chúng tôi đã sử dụng dữ liệu này cho tên tệp : prefix_1999_12_23_16_45_53.ext. Lý do chính: điều này rất dễ sắp xếp, TÌM KIẾM và phân tích cú pháp. Khi tìm kiếm, bạn thực sự muốn bắt đầu với đơn vị quan trọng nhất trước tiên để đạt được mục tiêu càng sớm càng tốt. Loại chuỗi này thậm chí là thân thiện với cây nhị phân. Phòng thí nghiệm bị chi phối bởi các sinh viên từ Châu Âu, nhưng tôi nghĩ đây chỉ là lẽ thường, nếu không phải là một tiêu chuẩn khoa học. Tuy nhiên, ở một đất nước nơi tôi lớn lên, chúng tôi sẽ sử dụng DD-MM-YYYY để sử dụng hàng ngày. Lý do: khi bạn thức dậy, phần đầu tiên bạn muốn biết là gì?
Công việc

2
@Frustrated, tôi đoán quan điểm của mình là có lịch với một năm khởi đầu khác nhau (làm thế nào một muslim giải thích ví dụ 1268/12/30?), Hoặc vài tháng trăng (trong đó có khoảng là. 13 mỗi năm) vv Vì vậy, để được thực sự phổ quát không chỉ là đồng ý về số nào là ngày và tháng nào ...
Péter Török

Câu trả lời:


15

Phần mơ hồ là phân biệt ngày với tháng nếu chúng được biểu thị bằng số.

02/03 có nghĩa là 03 tháng 2 hay 02 tháng 3?

Bằng cách thay đổi số nhận dạng tháng từ số của nó bằng tên của nó, bạn loại bỏ sự mơ hồ đó. Để trả lời câu hỏi của bạn, biến thể của bạn Feb 02, 2011dường như là một giải pháp tốt.

Vẫn còn một vấn đề tiềm ẩn với số năm nếu bạn chỉ viết nó với 2 chữ số, nhưng sau đó rất dễ khắc phục (sử dụng 4).


10
Và sau đó bạn có thể có một tệp dịch cho tên tháng bằng các ngôn ngữ khác nhau.
Thất vọngWithFormsDesigner

1
@FrustratedWithFormsDesigner Và đừng quên dịch một bản dịch chuyên nghiệp sang các chữ viết tắt chính xác (nổi tiếng).
Nicole

Còn những ngôn ngữ không bận tâm đặt tên tháng thì sao?
CHỈ CẦN HOẠT ĐỘNG CỦA TÔI đúng

19

Không. Không có định dạng ngày được công nhận trên toàn cầu.

ISO 8601 Xác định một tiêu chuẩn quốc tế cho các định dạng ngày. Như vậy, nó có lẽ là sự thỏa hiệp tốt nhất. Nhưng như bạn nói, người dùng không luôn thích định dạng này.

Giải pháp đúng duy nhất là trình bày một định dạng khác nhau cho các quốc gia khác nhau. Bạn có thể thấy rằng có một thư viện chuẩn để đạt được điều này nếu ngôn ngữ lập trình bạn chọn có một ý nghĩa quan trọng.


2
Điều đó thật tuyệt. Tôi thường sử dụng YYYYMMDD cho logfiles, v.v ... Bây giờ tôi có thể nói tôi chỉ đang tuân thủ ISO-8601!
Đánh dấu Harrison

1
Khi sử dụng ISO 8601, tôi thường thấy tốt nhất là định dạng toàn bộ nội dung, ví dụ 1999-12-25T00: 00: 00.000Z . Vâng, nó trông giống như vô nghĩa với người bình thường nhưng không có cơ hội mơ hồ.
MattDavey

2
"Giải pháp đúng duy nhất là trình bày một định dạng khác nhau cho các quốc gia khác nhau." - và chính xác, làm thế nào tôi có nên in một ngày trên phiếu đóng gói có thể giao hàng ở bất cứ đâu trên thế giới?
Scott Whitlock

@ScottWhitlock: Đáng buồn thay, không có giải pháp được chấp nhận phổ biến cho vấn đề này. Nếu bạn không biết nơi gửi gói hàng khi bạn in ngày, thì ISO 8601 có thể là lựa chọn tốt nhất của bạn.
Kramii

"Giải pháp đúng duy nhất là trình bày một định dạng khác nhau cho các quốc gia khác nhau." Tôi nói điều này không đúng. Hôm nay nó chỉ xảy ra rằng một số thư viện ý tưởng hữu ích về định dạng ngày ưa thích của tôi, dựa trên ngôn ngữ ưa thích của tôi, - gây nhầm lẫn. Nhưng là bước đầu tiên vì chúng tôi không thể sửa chữa tất cả các nền văn hóa ngay bây giờ, sử dụng ISO 8601 hoặc văn bản trong nhiều tháng hoặc một cái gì đó.
Erik I

9

Bạn nên sử dụng thông tin văn hóa cho điều đó. Hoặc ít nhất là định dạng hiển thị cục bộ.

Trong JavaScript, bạn có thể sử dụng phương thức toLocaleString cho lớp Date .

Đối với C #, bạn có thể sử dụng chuỗi định dạng khi sử dụng ToString .

Tìm kiếm nhanh trên Google sẽ cho bạn thấy cách sử dụng văn hóa theo ngôn ngữ bạn chọn.


5

Tôi sẽ đi với YYYY-MM-DD (và luôn viết ra năm chữ số bốn tháng và hai chữ số tháng và ngày). Theo hiểu biết của tôi, YYYY-DD-MM là không phổ biến, do đó, định dạng YYYY-MM-DD là định dạng ít mơ hồ nhất và cuối cùng người dùng của bạn sẽ nắm bắt được. Ngoài ra, bạn có được lợi thế sắp xếp tầm thường.


2

Bạn có thể cung cấp cho mỗi người dùng ngôn ngữ riêng của mình, sau đó hiển thị ngày và thông tin khác theo sở thích địa phương của họ không?


1

Nhiều lần bạn có thể định cấu hình ngôn ngữ và sử dụng I18n trong hầu hết các khung.


0

Trong trường hợp chung, bạn sẽ cần chỉ định cả định dạng và giá trị. Đây là cách duy nhất để tránh bất kỳ và tất cả sự nhầm lẫn. Ví dụ: bạn có thể nói "2011/02/02 (YYYY-MM-DD)". Mặc dù nó có chi phí đơn giản và dễ đọc, vì vậy hãy biết đối tượng của bạn.

Tất nhiên, bạn có thể nói "Sau đây, tất cả các ngày đều ở định dạng YYYY-MM-DD ...." Sau đó, "2011/02/02" xuất hiện sau đó sẽ không rõ ràng. Điều đó có thể ngon miệng hơn, nhưng một lần nữa, biết khán giả của bạn.


Phải, ngoại trừ trong tiếng Estonia ngày , trong tiếng Rumani: zi, lună, tiếng Thổ Nhĩ Kỳ: gün, ay, tiếng Việt: ngày, tháng ... không đề cập đến nhiều ngôn ngữ trong đó một tháng không bắt đầu bằng m hoặc ngày không bắt đầu bằng d (tiếng Đức: Monat, Tag ) cũng như các ngôn ngữ không sử dụng bất cứ thứ gì như bảng chữ cái Latinh.
Công việc

1
Chà, "2011/02/02" là không rõ ràng trong mọi trường hợp ...;)
Martin

0

Gợi ý này có thể là vô ích, nhưng tôi đã thấy nhiều tháng được viết dưới dạng chữ số La Mã. Chắc chắn, 3 / XI / 2011 có thể là ngày 11 tháng 11 hoặc ngày 3 tháng 3, nhưng tôi đoán cách giải thích đầu tiên là tự nhiên hơn.


1
Chữ số La Mã? "Tự nhiên?"
Wonko the Sane

@Wonko, "tự nhiên" theo nghĩa là trong bối cảnh đó, XI có nhiều khả năng được hiểu là một tháng hơn là một ngày. Tôi thừa nhận nó cực kỳ chủ quan.
ggambett

+1, tôi đã suy nghĩ một cái gì đó như thế này bản thân mình. Tuy nhiên, tôi cũng đồng ý với các nhà phê bình của bạn.
Công việc

Chưa bao giờ, chưa bao giờ thấy định dạng đó, trước tiên tôi nghĩ "lỗi đánh máy" hoặc "lỗi dịch thuật" trước khi nó phát hiện ra "chữ số La Mã". Chỉ sau đó tôi sẽ cố gắng đoán ý nghĩa.
Wonko the Sane

Chưa kể 3 / II / 2011 cuối cùng sẽ được hiểu là tháng 11.
MSalters

0

Tôi sẽ nói rằng nó phụ thuộc vào những gì bạn đang làm, bạn có bao nhiêu quyền kiểm soát đối với đầu vào và bạn có lưu trữ nó ở đâu đó không?

Để lưu trữ, tôi sẽ sử dụng những gì được đề xuất bởi Mike Dunlavey:

YYYYMMDDHHMMSS trong đó giờ ở UTC là con đường tôi đi bất cứ khi nào tôi có lựa chọn, vì những lý do bạn đưa ra. Khi tôi không có lựa chọn, tôi cho phép người dùng chọn.

Anh ấy đã không để điều này như một câu trả lời, vì vậy tôi sẽ.

Một điều nữa: hãy xem ảnh chụp màn hình sau đây về cách nhập ngày hết hạn CC: http://www.ubercart.org/files/credit_card_checkout.jpg

Điều tuyệt vời về ví dụ này là nó không khiến bạn phải suy nghĩ. Nó sử dụng cả số và tên trong tháng. Tôi sẽ xem xét sử dụng một cái gì đó tương tự cho đầu vào. Trong tháng, bao gồm cả số và tên địa phương. Đối với năm và ngày, sử dụng hộp số Lên / Xuống hoặc số. Sau đó, kiểm soát lịch cũng có vẻ tiện lợi.

Như tôi đã nói, nó phụ thuộc. Để lưu trữ: nếu sử dụng cơ sở dữ liệu, hãy kiểm tra xem nó đã cung cấp định dạng dữ liệu rõ ràng tốt chưa. Nếu sử dụng một số phương pháp khác, hãy xem "YYYYMMDDHHMMSS có giờ trong UTC" không. Để trình bày cho người dùng - hãy xem xét những quốc gia / địa phương nào có thể liên quan, sau đó chọn loại đại diện đơn giản nhất, "Đừng làm tôi nghĩ". Cũng xem xét việc cung cấp một tùy chọn.

Cuối cùng, hãy kiểm tra một số sản phẩm tuyệt vời đã làm một cái gì đó tương tự, và cố gắng tìm hiểu làm thế nào họ làm điều đó.


ah crap, khi đọc ảnh chụp màn hình tôi nghĩ rằng chúng ta đã nói về ngày 11 tháng 11 ... chỉ để nhận ra ngày đó là không cần thiết khi nói về ngày hết hạn của Thẻ tín dụng: /
Matthieu M.

@Matthieu M., vâng, đó là một chút sai lầm :) Tuy nhiên, nếu bạn đang cầm CC trong tay và sắp thực hiện nhập dữ liệu, thì có lẽ nó giúp ích nhiều hơn là đau. Nếu có ba hộp - một hộp trong ngày, thì điều này có thể ít mơ hồ hơn.
Công việc

0

Không có định dạng ngày và giờ phổ quát cho người dùng cuối của trang web. Cũng không có giá trị thời gian ngày duy nhất vì giá trị này khác nhau theo múi giờ của khách hàng. Bạn nên sử dụng toàn cầu hóa - nhắm mục tiêu dữ liệu, thời gian, tiền tệ, lịch, định dạng nubmer dựa trên văn hóa của người dùng (có thể nhận được từ các ngôn ngữ được chấp nhận được chuyển từ trình duyệt của người dùng hoặc bằng cách chuyển đổi được thực hiện trực tiếp trong ứng dụng của bạn). Một số API (ví dụ .NET) có hỗ trợ trực tiếp các tính năng này.

Để lưu trữ ngày và thời gian trong cơ sở dữ liệu, hãy sử dụng định dạng phổ quát - UTC (phối hợp thời gian chung).


UTC không phải là phổ biến: Nếu bạn muốn tính đến giây nhuận, bạn nên sử dụng TAI
mouviciel

-2

Thật không may là tất cả trí thông minh trong thế giới điện toán quốc tế không thể phá vỡ hạt này.

Không phải Microsoft cũng như các nhà cung cấp khác đã xem xét việc thêm mặt nạ ngày sẽ làm cho Tháng có vẻ không đầy, giống như Ngày, nhưng dưới dạng ba chữ số. Việc áp dụng thực hành sẽ giúp thúc đẩy một loạt các định dạng ngày sửa đổi mới tương đương về mặt toán học trong khi vẫn dễ dàng xác định và phân biệt trong bất kỳ bố cục ngày truyền thống nào. Đó là:

  • 0MM-DD-YYYY, ví dụ 002-03-2016 cho ngày 03 tháng 2 năm 2016

  • DD-0MM-YYYY, ví dụ: 03-002-2016 cho ngày 03 tháng 2 năm 2016

  • YYYY-0MM-DD, ví dụ: 2016-002-03 cho 2016/02/03

  • YYYY-DD-0MM, ví dụ: 2016-03-002 (nếu có ai muốn sử dụng nó!)

Có vẻ quá dễ để sửa nó theo cách này ... Tôi đoán đơn giản là không bán chạy.


2
Tất cả những gì tôi có thể nói là: xkcd.com/927 Chúng tôi đã có một tiêu chuẩn ISO cho ngày và không cần một tiêu chuẩn khác.
Simon B
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.