アメリカのユーザーも、2013年1月2日のような日付の日と月を混同しますか
米国以外のほとんどすべての場所で、短い日付です。 01/02/2013はコンピューター画面に表示されますが、ユーザーは最初の2桁が日または月を表すであるかどうか確信が持てません。 1月2日ですか、2月1日ですか。
米国外の人々は両方のフォーマットに定期的に遭遇し、システムがロケールに適応しているかどうか、またはアメリカのフォーマットに固執しているかどうかわからないため、これは米国外の人々にとって大きな問題です。しかし、私はアメリカのユーザーがほとんどアメリカのフォーマットを見ると思います（ほとんどではないにしても、多くの情報システムがアメリカ人によって、またはアメリカ人のために構築されているため）。私が気になるのはこのシナリオでアメリカのユーザーも混乱しているかどうか？
あなたがいくつかの証拠や研究を指すことができるなら、素晴らしい。そうでなければ、私はあなたの知識豊富な経験のために解決します。
注：月に名前を付けるというすばらしい解決策を求めているのではありません。 2013年5月21日。短い日付形式を使用する必要がある場合についてお伺いします。
私は公表された研究へのポインタはありませんが、私の経験では、米国人は米国以外のサイトを意図的に使用しており、潜在的な違いをすでに認識していない限り、常に米国のMM/DD/YYYY形式を想定します。
数値のみを使用する必要がある場合、私の経験において文化間で最も混乱を引き起こさない形式は、YYYY-MM-DDです。これは、両方の「デフォルト」とは異なり、想定に影響されないためです。
とは言っても、省略された3文字の月名を使用しても、余分な文字は1つしかありません。通常、数字を使用する場合のサイズ引数は偽です。
ISO 8601を参照してください（例 http://en.wikipedia.org/wiki/ISO_8601 ）
yyyy-mm-dd hh：mm：ss
まず、これは単に最大単位から最小単位までです。他の議論は、どんなにきつい場合でも、この論理を克服するようには思えません。
4桁の年は、ハイフンが省略されている場合でも、他の数値が何を表しているかについての混乱を取り除きます。 （2桁の年を任意の順序で使用すると、常に何かを確立できるわけではありません。）
数十年前にスタートレックカレンダーを見てこの出会い系スキーマを発見し、スターデートがyyyymm.ddであることに気付きました（注：スタートレックのものではなく、カレンダーを見ていました）。
私は軽度の失読症のアメリカ人です。私は、「逆」と書かれた十分な日付を見た（または認識した）ので、日（または年）も1〜12である場合、どの順序が意味するものと推定できるかを思い出すことはできません。 （「/」も避けてください。日付がわかりにくくなるためです。）
年月日をハイフンやスペースなしで使用することも、使用しないこともあります。そして、日と月が綴られている日、年月日。これは私の選択によるものです。必要な場合に備えて、ISO 8601はフォールバックの引数を提供するだけです。
注：一部のソフトウェアプログラムでは、たとえば、分を表す「mm」、月の数字を表す「MM」、および月のスペルを表す「MMMM」を使用する場合があります。 「hh」は12時間を意味し、「HH」は24時間を意味する場合があります。独自のソフトウェア内のこれらのコードはすべて、プログラマーの気まぐれの影響を受けます。
はい、あります。したがって Public Service Announcement xkcdから「...the数値の日付を書き込む正しい方法」についてです。
おそらく最初の年から始めるのでしょうか？最初は誰かを捨てますが、それには正当な理由があります。 YYYY-DD-MM構造を実際に目にしたことはありません。YYYY-MM-DDのみです。これは、ユーザーが日付を見るのに慣れていない場合があるかもしれないとユーザーに続いているようですが、それによって期待が明確になります。また、任意の日付形式（たとえば、イベントのグラフ）の近くにキーを配置することもできます。
混乱を避けるために、国際的に認識可能なdd-MON-yyyyの形式を採用することができます。たとえば、以下を参照してください http://www.Oracle.com/webfolder/ux/middleware/richclient/index.html?/webfolder /ux/middleware/richclient/guidelines5/commonFormats.html
ただし、サイト、ポータル、またはアプリが米国国内の市場またはビジネスのみである場合、米国の形式を想定するのが妥当だと思います。
または、日付が米国の形式で表示されることを通知する表記を画面に追加することもできます（例を示します）。
理想的には、UXは、ユーザーが快適な方法で日付形式を入力し、オンザフライ変換を実行して、ユーザーの好みに応じてレンダリングできる形式で日付を保存できるようにする必要があります。 UXの考慮事項により、ユーザーはロケールの規則内でもフォーマットを選択できるようになります。
たとえば、2011年1月28日の日曜日です。Jan-28-11やJan-28-2011などの短縮形式も使用できます。一般的なルールとして、視聴者が国際的であるか、その可能性が高い場合は、すべての数値の表示形式を回避する方が安全ですが、それはユースケースの範囲外と思われるため、2011年1月28日は許容されます。
アメリカ人が日付形式と混同する理由は、2013年1月2日が2013年1月2日であると想定しているためです。実際には、2013年1月2日（月日年）または2013年2月1日です。 （日月年）。年が前に移動するため、年月日の形式も混乱します。アメリカ人はこのように話すことに慣れていません。例：「あなたの誕生日はいつですか？」 「ああ、私の誕生日は4月2日です」。彼らはそれを得るでしょう、しかし彼らはそれに慣れていません。彼らはいつもこのように話します。例：「あなたの誕生日はいつですか？」 「あ、4月2日です」。 2013年2月1日のような数値の日付が表示された場合、その形式が日月年か月日年かを推測する必要があります。全体的にYYYY-MM-DDを使用します。 2019年5月29日14:24 UTC/GMT（2019-05-29T14：24：00 +0000 UTC）に記述