web-dev-qa-db-ja.com

どちらがより良い日付形式 "1991-11-01" OR "1991-Nov-01" ie "YYYY-MM-DD" OR "YYYY -MMM-DD」

私のアプリケーションでは、さまざまな方法でユーザーに日付を表​​示しています。

オプション1：テーブル形式で、ユーザーがテーブルをスキャンして、特定のアクティビティがいつ実行されたかを確認します。

enter image description here

オプション2：お客様の重要な情報として、DOB

enter image description here

日付の出力形式と一致させたいのですが、ユーザーが "1991-11-01"の日付をスキャンする方が簡単かどうかはわかりませんOR "1991-Nov-01 "フォーマット？同時に、顧客の情報を同じフォーマットで読み取ることができるはずです。

提案してください。

usabilityuser-behavioruser-expectationdatesformatting
4
AT - UID

私の意見では、月の名前を表示することをお勧めします。

私が住んでいる場所では、順序は常にDay/Month/Yearです。 他の一部の国 の間、一般的な順序はMonth/Day/Yearです。

ときどきインターネットで01/07/2000を見ると混乱します。First of JulyではなくSeventh of Januaryだからです。

だから私の提案はあなたの聴衆の言語で月名または略語を書くことです。

各要素が認識されている限り、順序はそれほど重要ではありません。

5
Alvaro

概要：YYYY-MMM-DDは、混乱の可能性がないため、優れています。

ユーザビリティコンサルタントであり執筆者であるSteve Krugは、「私に考えさせない」と言います。つまり、ユーザーがしなければならない思考の量（認知負荷）を減らしたいと考えています。

1991-11-01の代わりに1991-Nov-01（または11月）を使用することは、@ Alvaroが言うように、1991-07-01を7月1日または1月7日のように混乱させることがないため、明らかに優れたアプローチです。 、したがって、ユーザーが座ってそれについて考える必要があります。

@no comprendeは、国際郵便フォーマットに従って、月にローマ数字を使用することを引用していますが、ありがたいことにそれは綿密に行われていません。なぜありがたいですか？それも、人々が座って数字が何であるかについて考え、それを頭の中で月に変換することを必要とするからです。通常、ウェブサイトは1つの言語で記述されているため、国際化する必要はありません。国際化する場合は、月を翻訳します。 「7月」-彼らの言語に入れて、あいまいにならないようにします。

3
Nathan Keen

あなたの例は私がするフォーマットを使用しているようです。

ユーザーが多くの値を表示している表形式では、異なる長さの値があると気が散ります

7 April 2017     | 23004
12 December 2017 |  2340

これは、日付の部分をサブ列に配置することで少し軽減できますが、通常、サイズが一定の数値形式の方が優れています。

 7 April    2017 | 23004
12 December 2017 |  2340


2017-04-07 | 23004
2017-12-12 |  2340

代わりにローカライズされた数値フォーマットを使用できますが、ISO国際フォーマットはalmost国際的に明確です（ カザフスタンはyyyy.dd.MMを使用できます 、ハイフンを使用することでローカル形式ではなく国際形式であるかどうかを知るには、カザフ語のユーザーを見つける必要があります）。

フローテキストの場合、月の名前の綴りがより明確になることがよくあります。

1
Pete Kirkham

それはあなたがいる国に関することです。私は3つの国に住んでいて、人々は情報を表示するために独自の方法を持っています。それで、もしあなたがあなたの国のデザインを特にターゲットにすることができるなら、それをしてください。それが不可能な場合は、言語が変更されたときにいくつかのことを適応させることができます。たとえば、YYYY-MMM-DDは私にとって非常に混乱します。

0
Fede Crespo