DD / MM / YYまたはDD / MM / YYYY？
DD、MM、YYYYの順序についての議論がありましたが、デザイナーがYYよりもYYYYを選択する理由（たとえば、01/01/17ではなく2017年1月1日）についての議論はありません。
なぜそのような好みがあるのでしょうか？
YYYY全体をコンテキストに基づいて使用すると便利な場合もありますが、私が設計しているシステムが1世紀前のオブジェクトを処理しないと仮定すると、YYYY全体を必要としません。私は正しいですか？ YYだけを使用するのは問題ありませんか？
この質問に対する普遍的に良い答えはありませんが、YYYYには確かに2つの長所があります：
- 先行する2つの数値を表示することで、たとえば、 2011年から1911年、
- 年がXX01〜XX12の範囲の場合、年がどこにあるかを正確に把握できます。
言い換えると：
Notation Possible interpretations:
----------- -------------------------
09/10/11 Four:
September 10th 2011
9th of October 2011
2009, 10th of November
2009, October 11th
09/10/2011 Two:
September 10th 2011
9th of October 2011
2009/10/11 Two as well:
2009, 10th of November
2009, October 11th
ご覧のとおり、年を指定することでユーザーに懸念を限定できます。日付が31より大きい数値で終了する年（他のフィールドで可能な最大の数値）である場合、興味深いことが起こります。
Notation Possible interpretations:
----------- -------------------------
09/10/33 Two:
September 10th 2033
9th of October 2033
ただし、上記の解釈では、ユーザーが最初に文字列の内容を分析する必要があるため、認知負荷が大幅に増加します。考えは次のようになります。
"09は年ですか？わかりません。真ん中は年ではありません。おお、33は年です。したがって、09は日または月でなければなりません。"
もちろん、これは瞬く間に起こります（まあ、そのうちの2つ。まあ、3つです）が、それは認知的負荷であり、ユーザーがこの形式で多くの日付を処理する必要がある場合は、彼らが学ぶまで、年を何度も検索する同じ歓迎されないプロセス。そして、彼らは学ぶ必要はありません。
これらについては、内容を気にする必要はありません。年が隠された文字列を見ているだけの場所を簡単に確認できます。
- ▓▓-▓▓-▓▓▓▓
- ▓▓/▓▓/▓▓▓▓
- ▓▓▓▓/▓▓/▓▓
- ▓▓▓▓-▓▓-▓▓
- ▓▓▓▓-▓▓
- ▓▓-▓▓▓▓
日と月の問題：段階的アプローチと文化的アプローチ
ここで、日付が非常に不明確である本当の原因を突き止めます。月と日です。今年の問題は解決しましたが、ここで別のものと区別する必要があります：▓▓/▓▓/▓▓▓▓
Notation Possible interpretations:
----------- -------------------------
09/10/2033 Two:
September 10th 2033
9th of October 2033
私にとっては、時間の単位が一貫して低い方から高い方へ（つまり、DD/MM/YYYY）、またはその逆（YYYY/MM/DD）になる漸進的なアプローチがより理にかなっています。残念ながら、ユーザーが時々しかアプローチしないシステムでは、このアプローチを使用しても問題ありません。これは、使用したことを覚えていないためです。それ。
一方、日付のMM/DD/YYYY形式は、米国、カナダ、グリーンランド、フィリピン、およびいくつかのアフリカ諸国（ source ）で一般的です。これは、日付の省略形です。発音：「2017年9月10日」。ただし、別の発音も許可されているため、これは混乱のみをもたらします。
この狂気から抜け出すには、MMをそのテキストバージョン（たとえば、短縮：OCT/10/2017または09/SEP/2017）に変更することを検討できますが、この場合、国際ユーザーの翻訳の問題に陥ります。
専門的な使用法
表記法を気にする必要がない1つの状況は、ユーザーが主に専門的な方法で日付データを処理する状況です。私が頭の中でお伝えできる2つの例は、金融アナリスト（市場の変化を観察している）と、彼らが心から知っている慣習を使用して名前が付けられた多くの写真を扱っている写真家です。彼らがそれを暗記しているのであれば、これは問題ではありません。
「現在」のコンテキストアンカー
日付の年が何であるかの重要性がそれほど重要でなくなる別の状況は、ユーザーが「今」を重視する場合です。 Facebookはその好例です。
省スペース
スペースを節約することは、意思決定を行う上で非常に重要な要素になる場合があります。繰り返しになりますが、多くのデータを含むダッシュボードでは、年が完全に廃止されているか、切り捨てられる必要がある場合があります。しかし、私はこれらのダッシュボードはほとんどの場合、専門的な使用法のバスケットに分類されるので、あまり心配する必要はありません。
1つのテキスト文字列に結合してソートする
場合によっては、日付を1つの大きなテキストにまとめる必要がある状況に直面することがあります。たとえば、写真ファイルに使用する命名規則はYYYYMMDD_HHmmSS.ext（例：20170911_113426.RAF）です。これも、「プロ」使用バスケットに分類されます。ただし、ファイルの日付属性が変更されることを心配する必要なく、日付で並べ替える手段も提供します（たとえば、この種類の属性をサポートしていないファイルシステムに移動された、またはアプリで編集されたため、それをクリアするため） ）。この使用シナリオは、2つの結論をもたらします。
- 少なくとも2000年の写真は1999年の写真より後になるので、1年を過ごすのは良いことです。
- 高いユニットから低いユニットへと段階的に変化していくのが良いでしょう。
要約：
ユーザーはシステムを暗記していますか？彼らは日常的に日付属性を使用していますか？その場合は、年がどこにあるかを気にする必要はありませんが、並べ替えや一意性などの追加事項を検討してください（たとえば、日付の範囲が広い2011年からの1911年）。
ユーザーがたまにしか日付属性に近づきませんか？もしそうなら、彼らの側からの高い認知負荷なしで日付の何が何であるかについてより高い認識を提供してください：年を4桁に拡大し、月がどこにあるか明確にしてください。スペースが重要な場合を除いて、その場合はトレードオフに備える必要があります。
編集：
以下のコメントの多くはISO-8601規格に言及しているので、元の回答に追加しなかった理由を説明したいと思います。
単語「標準」には、基準と慣習という2つの意味があると思います。
規約は、限られた人々のグループが使用するものへの一般的なアプローチです。このような特定のトピックに関しては、さまざまな規則が存在する可能性があり（通常は存在します）、そのうちの1つが別の規則と矛盾する可能性があります（ここでも同様です）。さらに、ほとんどの規則は標準と矛盾し、標準はほとんどの規則と矛盾しています。
条約には、歴史的、言語的、実用的などのルーツがあります。たとえば、日付の規則の場合、MM/DD/YYはアメリカの方法で日付を「2008年11月5日」と言いますが、他の場所では異なる場合があります。
normに移ります。
normは、これまでに使用されたほとんどの規則を否定し、それらのほとんどを置き換える役割を持っています。これは、標準として選択された規則の1つになる可能性がありますが、1つだけを残す必要がある場合は、ほとんどの規則を拒否する必要があります。通常、規範はよく考えられています。この特定の場合の基準は、その次の単位が前の単位よりも小さいため、非常に理にかなっています（これにより、日付間の比較、テキスト文字列としての日付による並べ替えなどが容易になります）。
ここから移動するには2つの方法があります。
1つは、世界中で使用されている標準の一貫性を長期的に提供して、どこでも使用されるまで標準をプッシュすることです。いつも使っていたものとは違うものを使うように人々に強いることには欠点があり、これはある程度、使いやすさに反しています。
他のオプションは、人々が理解する地元の慣習に適応することです。文化的、言語的、実用的な理由から派生したため、慣習feelはローカルでより適切です。しかし同時に、Webの閲覧中に他の慣例を使用している人々が他の慣例にも出会うと、慣れ親しんだものとは異なる何かを目にすると混乱する可能性があり、このアプローチを使用すると、ある程度、使い勝手が悪くなります。
このように、私はまだこの質問に対する普遍的に良い答えはなく、すぐには表示されないかもしれないと私は信じています。ここでできることは、年を2桁ではなく4桁で表記する場合のように、いくつかの混乱を制限することです。
原則として、2桁の年を使用してもneverOKです。 4桁の年を使用すると、何千もの赤ちゃんとかわいいふわふわのウサギがひどく死ぬことを証明できる場合、それは規則の例外になる可能性がありますが、おそらくそうではありません。
プログラマーが2桁の年または現地の日付イディオムthisの時間を使用することは完全に問題ないと考えたからといって、何百ものコストのかかるプロセス障害を見てきました。
しかし、 YYYY-MM-DD ISO 8601標準日付形式 を選択したためにプログラムまたはプロセスが失敗することは一度もありません。それは常に正しい選択です。このアドバイスを心に留めてください。後悔することは決してありません。
YYYY-MM-DDの標準形式は、どの国のどの年齢の人でも同じように理解できます。たとえば、MM/DD/YYやDD/YY-MMなど、従来の形式が客観的なものである国で生まれたものでも同様です。また、再フォーマットせずに正しくソートされます。これはボーナス機能です。
この例を見てみましょう：1/02/07。
最初は、何でもかまいません。それでは、YYYY：1/02/2007にします。
かなり違いますよね？これは、YYYY形式の主な理由の1つです。 2桁/ 2桁/ 4桁形式のデータポイントはほとんどないため、多少の混乱を避けることができます。
世紀の古い出来事を扱っていないとき-YYYYの代わりにYYを使用することは完全に理にかなっています。
Stackexchangeも同じパターンに従います。
「2009年1月6日の質問」
MM/DDまたはDD/MMは大陸ごとに変わります ですが、YYまたはYYYYは世界全体で同じです（少なくとも英語を公用語として使用する国では）。
ISO 2014 は置き換えられますが、元々、すべての数値の日付表記をmost-to-least-に導入した標準です有意な順序[YYYY]-[MM]-[DD]。 ISO週番号付けシステムはISO 2015で導入され、序数による日付の識別は元々ISO 2711で定義されていました。
切り捨てられた表現
ISO 8601：2000では、日付または時刻の先行コンポーネントが省略されている（合意により）切り捨てが許可されていました。特に、これにより2桁の年を使用できるようになり、あいまいな形式YY-MM-DDおよびYYMMDDが許可されました。この規定はISO 8601：2004で削除されました。
MS Window 10から：
YYオプションは完全に有効です
私はyyではなくyyyyに関する議論がy2kの前段階で扱われたと思いましたか？これを読んで、2099年が2100に変わるのを見ると生きている人はほぼ確実にいます。そして、コードが恐ろしい洋ナシ形になるレッスンを学ぶのに失敗したプログラマーが2100年に来るでしょう（それがまだ使用されているとき）。誰か、どこかに）。
また、人々は増え続ける数で彼らの100歳の誕生日を超えて生きています。ユーザーが入力した生年月日が常に100年未満であると仮定することは、近い将来、非常に悪い仮定になる可能性があります。私は最初の学校の選択に関する104歳の年金受給者の両親に宛てられた手紙をすでに読んだ-小学校でのこれらの年金受給者の不在に関する法的脅威はすぐに続くだろう！
この質問がstackexchangeのUXセクションで行われたことを考慮すると、答えはユーザーの期待に焦点を当てるべきだと思います。
私は個人的に大規模なY2Kプロジェクトで働いており、ソフトウェア開発者がそのようなプロジェクトから教訓を学んだことを期待しています。ただし、そのレッスンが何であるかについては、依然として一定の意見の相違があるようです。 2桁の年が常に悪であることはではありません。
年の値を2桁で格納する主な理由は、ストレージメモリを節約することであったというのは歴史的な誤解です。真実はユーザーが不要なデータを入力したくなかったので、主にインターフェイスで2桁の年を望んでいました。 開発者の責任は、ユーザーインターフェイスデータと格納されたデータを区別することではありませんでした。 4桁で保存されていれば、ユーザーインターフェイスで2桁の年を使用しても問題ありません。そうすれば、あいまいさが数年後ではなく即座に検出されます。
結果として、UXに関して言えば、ユーザーインターフェイスで2桁の年を使用することは完全に許容されます
- 与えられたコンテキストではあいまいではありません
- 常に4桁の値として保存されます
「与えられた文脈」を説明するには：
- 予約サイトのフライト日付は2桁の年でうまく機能します。これは、ユーザーが100年以上先のフライト日付を予約することができないためです。
- 少なくとも一部の人は100歳以上になるため、誕生日の日付が2桁の年でうまく機能することはほとんどありません。
YYよりもYYYYを使用すると、3つのフィールドのどれが年を表すかがすぐにわかります。これにより、異なる世紀間だけでなく、日付形式間のあいまいさが解消されます。ただし、DD/MM/YYYYが受け入れ可能な表現になることはほとんどありません。
表示する場合は、「2017年4月4日火曜日」のように長い形式を使用することもできます。明確で明確ですが、スペースが大きく変動するため、他の言語への翻訳が必要になる場合があります。
数値表現の場合は、常にYYYY-MM-DD（ ISO 8601 ）を使用します。これは、曖昧さがないことが保証され、ISO標準であり、コンピューターと人間の両方（他の慣れしているユーザーでも）で簡単に解析できます。形式）、ローカリゼーションは不要であり、字句ソートによって時系列で並べ替えることができます。
YYの利点：
- 2文字分のスペースを節約
- 日付を入力するときに0.2秒の時間を節約します。
YYの短所
- 同じ製品で異なる日付形式を使用する必要があります（場合によっては、ある時点でYYYYを使用する必要があります）
- あいまいさを追加します（どの世紀ですか？）
- あいまいさを追加します（年と月はどちらですか？）
- あいまいさを追加します（年と日はどちらですか？）
- 読み取りに0.2秒かかる（あいまいさのため）
- ユーザーエラーのリスクが増加します（入力検証が悪い、およびあいまいさのため）
- プログラミングエラーのリスクが高まる（通常は並べ替えが必要）
ユースケースに基づいて、長所と短所を互いに比較する必要があります。次の最良の選択肢がLEDディスプレイのスクロールである場合、これらの2文字を保存することは突然重要になります。入力の.2秒を節約することは、ユーザーが1日に1,000個の日付を入力する必要があるワークフローで非常に役立ちます。しかし、他のほとんどすべての場合、バランスは逆方向に傾きます。
Y2Kの切り替えにより多くの作業が発生しましたが、これは金銭的な観点からは良好でしたが、実際には退屈の作業でした。私は2100を見るために生きるつもりはありませんが、私たちの相続人を退屈させないでください...
（十分に明確ではありませんか？1985年から1999年にかけて、私たちは全員、システムのアップグレードに長い時間を費やしました。
ほとんどの人はDD/MM/YYYY形式を使用しています。地域/国に基づくフォーマットはさまざまです。 国別の日付形式
タイムスタンプの場合、ファイル名またはディレクトリ名では、常にYYYYmmddを使用して、通常の字句ソート（例：ls -l command）は常に正しい順序でものをリストします。 mmddYYYYもddmmYYYYもそのプロパティを持ちません。
手書きのメモでは、便宜上、世紀を混乱させないために、単にYYmmddを使用することがあります。
もちろん、9999年には、この表記は再び大きな不安を引き起こします。
それはあなたが達成しようとしていることに依存します。場合によっては（おそらく想像以上に）、ユーザーは4桁の年を表示する必要があるかもしれませんが、2桁の年で十分な場合もあります。考慮しなければならないのは100年前のイベントだけではなく、ユーザーが日付を入力することをどのように期待するかによって異なります。ここではいくつかの例を示します。
- 生年月日： 1999は2000年より前ですが、99は00の後にソートされるため、ドロップダウンのようなDOBの場合、4桁の年が理にかなっています（2桁が表示されますが、4でソートされます実行可能ですが、ユーザーを混乱させる可能性があります）。
- Calendar app： Googleカレンダーのインターフェースはこれには理想的ではありませんが、POSIXエポックの前にイベントを追加できます-60年代の日記があれば、それらをgoogleにデジタル化できます（それは悪い考え、それから私は生まれたくない。あるいは、おそらくそれを使用して、23世紀の新しいセットを計画することもできます。 汎用的なものを構築する場合、ユーザーはこれまで以上に多くの用途を考え出すでしょう。
少し意見：この透明性/柔軟性は、スペースの節約に勝るものです。
一方、より制限された時間枠で作業することは可能です。劇場のチケットを販売していて、イベントが翌年くらいにしか発生しない場合、ユーザーは2桁の年を表示するだけで済みます。この場合、過去の注文でさえYYだけで完全に意味があります。
私の見解を書く前に、@ Dominik Oslizloによる素晴らしい答えだと言わなければなりません！
わかりました、年の形式については、それは完全に以下に依存すると思います：
- 対象者（その地域）-アジアの国のユーザーは、最初に日付を言ってから月を指定することを好みます。北米や西側諸国では逆です。たとえば、9/11はアメリカの日付を伝える方法ですが、インドでは26/11です。どちらの日付もテロ攻撃に関連しているため、これは興味深い例です。 9/11（9月11日）、世界はそれについて知っており、26/11（11月26日）はムンバイ攻撃について知っています。それが参照される方法は注目に値します。それは文化を反映しています。
ですから、日付と月を混同する可能性はすでにあり、年は完全に記述されています（YYYY）
- 目的（イベントを確立するために日付と年を尋ねる目的が最近起こった場合、またはそれが誕生日である場合）誕生日のケースを想像してみてください。ユーザーがyy形式のみで言及されている場合、ユーザーが19yyまたは20yyで生まれたことを確認できる方法はありますか？.
結論：
あいまいさを避けるために、DDMMYYYY形式に従ってください。それは私たちが日常生活の中で年を参照する方法をサポートします。 20 17や2k17などと言う傾向がありますが、完全なYYYY形式です。
したがって、ユーザーの考え方をサポートしてください。したがって、YYYYは常に明確になります。
正直なところ、日付に関しては、アメリカ人がいるからといって、月には常に3桁の表現を使用しています。
多くの人が09/10/11は10月9日または9月10日である可能性があると指摘していますが、09/Oct/11がある場合、すべてのユーザーがあなたが探しているものを知っています。
それか、またはユーザーがフィールドが何であるかを知るための何らかの（明白な）方法がある（たとえば、質問に「in（dd/mm/yy）」形式を入力するか、入力にプレースホルダーテキストを使用する）
何年かになると、yyを使用する方がはるかに簡単ですが、使用目的によって異なります。医療フォームの場合、1920年代に生まれた人がフォームに記入することは不可能ではありません。したがって、股関節置換を必要とするフォームに赤ちゃんが記入しているように見えると、数年後にフォームが非常に混乱することがあります。