Webサイトやアプリケーションなど、オンスクリーンの日付表記（日付フォーマット）の選び方についての記事です。視認性や見た目の印象などのデザイン観点から、比較検証した結果や考えたことをまとめました。

前提

この記事ではオンスクリーンのUI（ユーザーインターフェイス）として、テキストで日付を扱う場合に焦点を当てています。印刷物やバナーなどのグラフィック表現では別の観点が必要になります。

対象とするUI（ユーザーインターフェイス）の言語は主に日本語を想定しています。記事の後半で他言語対応についても少し触れています。

自分が知らないことや気付いていない観点もあり、より良い方法や慣習的に別の方法が良いということも考えられます。お気付きの点がありましたら、TwitterのDMで教えていただけると嬉しく思います。

結論

日付表記について検証した内容やこれまでの経験則から判断した結果、状況に応じて選ぶのが良いという結論に至りました。

汎用的な日付表記の候補

汎用性を重視する場合は、多くの状況に対応しやすい以下2つのいずれかが良いのではと考えています。

• 2020年6月25日 17:15
• 2020-6-25 17:15

そう考えた経緯や判断材料については後述します。

多くの状況に当てはまりそうと感じた点

「どの日付表記が最適かは状況次第」というのが結論ですが、多くの状況に当てはまりそうだと感じたことも見えてきました。例えば以下の点です。

• 表記を統一する。
• ゼロパディング（ゼロ埋め）無しで表記する。
• 事前に他言語対応をどうするかの方針を決めておくと良い。
• 特別なこだわりが無ければ、ISO 8601に準拠する方法が良いかもしれない（この点は検証不足なので要検討）。

判断材料を書き出す

以上を元に日付表記をデザインする際にどの表記を選ぶと良いのか、視認性や見た目の印象も含めて、判断材料を書き出してみます。

そもそも視認性とは何か

視認性とは、対象物を正しく正確に理解できる度合いや、確認のしやすさとして定義されています。

目で何かを見た時に，対象物やその対象物がもつ意味合いについて，正しく確認・理解できるかどうかの度合い。「―に優れる」

辞書.app（スーパー大辞林）

目で見たときの確認のしやすさ。デザインや人間工学の分野において、背景に対し色や形が際立っていたり、文字が大きくてわかりやすかったりする度合い。「視認性の高いデザイン」

コトバンク

デザインを良くするため、視認性を高める理由を次のように捉えています。

• ユーザーが情報を誤解無く理解できるようにする。
• ユーザーが情報を理解するまでに必要な労力を可能な限り減らす。
• ユーザーが情報を理解するまでの速度を可能な限り上げる。

表記を統一する

日付に限りませんが、Webサイトやアプリケーションにおいてデザインの一貫性を保ち、ユーザーにコンテンツに集中してもらうために、表記は統一したほうが良いです。理想はWebサイトやアプリケーション内で、日付表記が統一されている状態です。例えば以下のような状態であれば改善余地があります。

• ページによって日付表記が異なっている。
• 同じページ内で場所によって日付表記が異なっている。
• 例えば、場所によって2020年6月5日や2020/6/25、2020-6-25など、異なる日付表記が使われている。

もし何らかの理由や経緯で日付表記が統一されていない場合は、統一化でデザインを改善できる可能性があります。

ゼロパディング（ゼロ埋め）の有無

ユーザーが使う画面に日付を表示する場合は、ゼロパディング（ゼロ埋め）無しのほうがすっきりと見えます。以下に例を挙げます。

• ゼロパディングあり：2020年06月05日
• ゼロパディング無し：2020年6月5日

ゼロパディングとは何か

数値表記の際、指定された書式に合わせるために足りない桁数をゼロで埋めて表現することです。Wikipediaには次のように書かれています。

ゼロパディング又はゼロ埋めは、文字で数値を表す際に、書式で指定された桁数に満たない場合に、桁数をそろえるためゼロを付加することである。

Wikipedia

ゼロパディングを無くしての表記の違和感を減らす

一般的なカレンダーではゼロパディングありで表現することが稀なこともあり、「2020年06月05日」のようなゼロパディングありの表示は、情報としては理解できるものの違和感を感じやすいのではないでしょうか。

例えば「システム的にゼロパディングありにしないと動作が安定しない」といった特別な理由がない限り、ゼロパディング無しで表現することを推奨します。

仮に「何らかの項目の並べ替え順序に影響する」ということであれば、ゼロパディングありは検討余地があります。ただその場合でも並べ替え順を指定するキー（属性）を整理して並べ替え順序を制御できるようにしたほうが、ユーザーの利便性が上がると考えます。

ゼロパディング無しにする理由は、ユーザーにコンテンツに集中してもらうため

理由はユーザーにとってのノイズを少しでも減らして、コンテンツに集中してもらうためです。これまでに関わったWebサイトやアプリケーション構築のプロジェクトでも、特別な理由がなければゼロパディング無しで表現していました。

例外的にゼロパディングを付ける場合

例外的にファイル名のタイムスタンプは、ゼロパディングありで名前を付けています。

例：filename-20200625.ai

音声読み上げの安定度

音声読み上げソフトでどのように読まれるかも観点の1つです。以下の場合どのように読まれるかを検証しました。

A：2020.6.25
音声読み上げ：にせんにじゅう、ろく、にじゅうご（意図しない結果）

B：2020-6-25
音声読み上げ：にせんにじゅうねんろくがつにじゅうごにち（意図した結果）

C：2020/6/25
音声読み上げ：にせんにじゅうねんろくがつにじゅうごにち（意図した結果）

D：2020年6月25日
音声読み上げ：にせんにじゅうねんろくがつにじゅうごにち（意図した結果）

この中では、B、C、Dはいずれも安定して「にせんにじゅうねんろくがつにじゅうごにち」と読まれました。

Aは音声読み上げソフトウェアの違いによって、「にせんにじゅう、ろく、にじゅうご」のように意図しない内容で読み上げられる場合と、「にせんにじゅうねんろくがつにじゅうごにち」と正常に（意図通りの内容で）読み上げられる場合がありました。

例えばmacOSのテキストエディット.appでは、Aの日付表記でも「にせんにじゅうねんろくがつにじゅうごにち」と正常に読み上げられました。ソフトウェアの対応度によりますが、安定度の観点でB、C、Dが優れていました。

狭いコンテンツ幅での表示のしやすさ

UI（ユーザーインターフェイス）として日付を表示する場合、表示領域も1つの観点になります。最大文字数で表示した際にコンテンツ幅に収まるよう設計する必要があります。

A：2020.6.25

B：2020-6-25

C：2020/6/25

D：2020年6月25日

狭い幅での表示のしやすさではAが最も優れています。使用するフォントによりますが、BとCはほぼ違いが無いようです。

ユーザーの誤解の少なさ

表示領域と別の観点ですが、誤解の少なさも重要だと考えます。

A：2020.6.25

B：2020-6-25

C：2020/6/25

D：2020年6月25日

日本語表記の場合に限りますが、誤解の少なさの観点では解釈が限定されやすくなる理由から、Dの表記方法が優れていると考えます。

時刻表記と組み合わせた場合の視認性

A：2020.6.25 17:15

B：2020-6-25 17:15

C：2020/6/25 17:15

D：2020年6月25日17時15分

E：2020年6月25日 17:15

誤解の少なさではDかEが優れており、表示領域やすっきりとした印象の優先度が高ければ、AかBが優れていると考えます。誤解の少なさや表示領域、見た目のすっきりとした印象のバランスが良いと感じるのはEの表記です。macOSのFinderの日付表記と同様です。

期間を表記する際のタイポグラフィの作法

欧文のタイポグラフィでは、期間や時間、場所から場所の表示にはハイフン「-」ではなく、半角ダーシ［半角ダッシュともいう（en dash）］「–」を使うと『欧文組版 組版の基礎とマナー』に書かれています。

例：2018–2021

例：July 20, 2021–July 23, 2021

基本は半角ダーシの左右にはスペースを開けずに使いますが、読みにくくなってしまう場合はCSSで調整して、少し余白を設けたほうが良いかもしれません。

期間を表記する場合の視認性

A：2020.6.25–2020.7.15

B：2020-6-25–2020-7-15

C：2020/6/25–2020/7/15

D：2020年6月25日–2020年7月15日

E：2020年6月25日〜2020年7月15日

こちらも誤解の少なさではDやEが優れているように感じます。その次にA、C、Bと続く印象を受けました。

日本語（和文）の場合は期間表記に「〜（波ダッシュ）」が使われることが多いようです。

Bはハイフンと半角ダーシ（en dash）を使って期間を表現しているのですが、ぱっと見の印象ではハイフン（-）と半角ダーシ（–）の違いが判別しにくく区切りがはわかりにくいため、半角ダーシの左右にCSSか半角スペースで余白を設ける調整をしたほうが良いかもしれません。

調整をかけた例：2020-6-25 – 2020-7-15

時刻と期間を組み合わせた場合の視認性

A：2020.6.25 17:15–2020.7.15 17:15

B：2020-6-25 17:15–2020-7-15 17:15

C：2020/6/25 17:15–2020/7/15 17:15

D：2020年6月25日17時15分–2020年7月15日17時15分

E：2020年6月25日17時15分〜2020年7月15日17時15分

誤解の少なさではDとEが優れているように感じます。次にAとCがほぼ同様の視認性で、Bがその次でしょうか。期間指定と同様に半角ダーシの左右にはスペースを設けたほうが視認性が高まるかもしれません。

半角ダーシの左右にスペースを設けた場合

A：2020.6.25 17:15 – 2020.7.15 17:15

B：2020-6-25 17:15 – 2020-7-15 17:15

C：2020/6/25 17:15 – 2020/7/15 17:15

日付表記の名前でファイルとしてダウンロードする場合

システムとして「日付の名前でファイルを生成してダウンロードする」場合を想定しました。

A：2020.06.25.jpg

B：2020-06-25.jpg

C：2020/06/25.jpg（ファイル名にスラッシュは使えないので除外）

D：2020年06月25日.jpg

ファイル名としてはBが最も適切だと考えます。Aはファイル名にドットが入ることになり、拡張子のためのドットと混ざるリスクを減らせるという観点でBが優れていると考えます。Dでも対応はできますが、OSを横断した安定したファイル名の観点では、半角英数で表記できるBが優れていると考えます。

OSのファイルシステムの仕様上、ディレクトリの階層区切りを意味する「/（スラッシュ） 」はファイル名には使えないため、Cは必然的に除外します。

他言語対応の方針を検討する

国によって日付表記の方法が異なっており、他言語対応における完全な表記の統一化は困難なようです。例えば、日本、アメリカ、イギリスでも次のように異なります。

日本：2020/6/25（YMD：年、月、日の順）

アメリカ：6/25/2020（MDY：月、日、年の順）

イギリス：25/6/2020（DMY：日、月、年の順）

Date format by country – Wikipedia

日付表記をシステム的に切り替える場合

他言語対応が必要かつ国ごとに日付表記を変える場合は、例えばJavaScriptを用いてシステム的に表記を切り替える方法があるようです。

jsでの国際化（数値と日付のフォーマットについて） -Qiita

Intl – JavaScript | MDN

日付表記を完全に統一したい場合

他言語対応が必要かつ日付表記を完全に統一したい場合は、後述する日付表記の国際規格であるISO 8601を用いるのが良いかもしれません。

ISO国際規格のISO 8601を用いる場合と改善方法

日付表記（日付フォーマット）について調べたところ、ISO 8601という日付表記の国際規格があることを知りました。

ISO 8601形式 – Wikipedia

ISO 8601の日付表記には基本形式と拡張形式の2種類があるようです。その1つの拡張形式による表記が視認性にも優れていると感じるので、ISO 8601に沿った表記で統一する方法もあります。

ISO 8601の拡張形式

2020-06-25T17:15:00+09:00

日付と時刻をT記号で区切るルールによって「T」が含まれていたり、タイムゾーンを明示するため「+09:00」が含まれていたりします。

ISO 8601の拡張形式をより読みやすく調整する

拡張形式のままだと情報量が多く、見慣れないユーザーにとっては複雑な印象を与えてしまう可能性が高まります。その対策として拡張形式をそのまま使うのではなく、少し調整をかけることで読みやすさが高まるのではないかと考えました。以下は調整した例です。

調整前：2020-06-25T17:15:00+09:00

調整後：2020-06-25 17:15

情報を限定して表記することで、よりわかりやすい印象になったのではないでしょうか。

期間表記の場合

2020-06-25/2020-07-15

ISO 8601では期間表記の区切りとして「/（半角スラッシュ）」を使うルールになっているようですが、一般的にあまり見慣れない表記です。

期間表記を読みやすく調整する

もし期間の区切り記号として「/（半角スラッシュ）」を用いるとしても、左右にスペースを開ける調整をかけたほうが視認性が高まりそうです。

調整前：2020-06-25/2020-07-15

調整後：2020-06-25 / 2020-07-15

開発者向けの情報であったり、データフォーマットとして汎用性を持たせたい場合はISO 8601のままの表記が表記が適しているかもしれません。一方でユーザーが目にする日付表記としては複雑でわかりにくく感じるので、より読みやすくなるように調整をかけたほうが良いと考えます。

まとめ

記事の前半で触れましたが、汎用性を重視して判断すると以下の表記が扱いやすいのではないかと考えています。

汎用的な日付表記の候補

• 2020年6月25日 17:15
• 2020-6-25 17:15

判断理由は、多くの状況に対応しやすいと考えたためです。

最後に

視認性やデザインの観点から日付表記を比較検証をして、判断材料を書き出してみました。

細かいことかもしれませんが、日付表記の違い1つを挙げてみてもUI（ユーザーインターフェイス）の使いやすさやデザインの印象、データの運用方法への影響は大きいはずです。

今後のデザインにおいて、日付表記を選ぶ際の判断材料として振り返ったり、何が最適かの検証に活用したいと考えています。