PC版アプリ(Webアプリを含む)の日付表記を調査しました
はじめに
画面に日付を表示する際、日付表記を何にすべか悩むときがあります。
- ハイフン区切り、スラッシュ区切り、ピリオド区切り、年月日か
- ゼロ埋めするか否か
- 曜日を表示すべきか
- 期間を表す文字は波線かハイフンか
どの日付表記にするかを決めるにあたって、他のアプリを参考にしようと思い、有名なアプリではどの日付表記を採用しているか調べてみました。
なお、各日付表記の特徴について、以下の記事が参考になりました。
日付フォーマット
-
YYYY
:西暦4桁 -
MM
:ゼロ埋めした月(01,02,...12) -
M
:ゼロ埋めしていない日(1,2,...,12) -
MMM
:英語の月の短縮系(Jan, ..., Dec) -
MMMM
:英語の月の正式名称(January, ..., December) -
DD
:ゼロ埋めした日(01,02,...31) -
D
:ゼロ埋めしていない日(1,2,...31) -
aaa
:日本語の曜日1文字(日, ..., 土) -
aaa
:日本語の曜日の正式名称(日曜日, ..., 土曜日) -
dddd
:英語の曜日の正式名称(Sunday, ..., Saturday) -
ddd
:英語の曜日の短縮形(Sun, ..., Sat) *
用語
説明しやすくするため、以下の用語を定義します。
- 区切り表記:
YYYY-MM-DD
,YYYY/MM/DD
,YYYY.MM.DD
など、記号1文字で年月日を区切る表記 - 漢字表記:
YYYY年M月D日
調査方法
調査日
2022/02/01~2022/02/14
調査対象アプリ
- PC版(Windows11)アプリ(Webアプリを含む)
- 日本語対応
調査しないこと
- 時間表記
調査結果
Slack(PCアプリ版 日本語表示)
メッセージ
- メッセージの区切り:
M月D日 (aaa)
- 日時にカーソルを当てたときに表示されるツールチップ:
M月D日
M月D日 (aaa)
M月D日
期間での検索
- 検索クエリ:
YYYY-MM-DD
- 期間表示:
M月D日~M月D日
期間を指定するテキストボックスは2022-02-01
と表示さています。また、検索クエリも2022-01-31
と表示されています。
検索クエリは直接入力するので、YYYY年M月D日
形式ではなくYYYY-MM-DD
形式にしたのでしょう。また、日付テキストボックスは検索クエリと連動しているため、日付テキストボックスもYYYY-MM-DD
形式なのだと考えられます。
なお、日付テキストボックスでは2022-02-01
と表示されていますが、検索クエリは2022-01-31
と表示されています。境界値の扱いが、日付テキストボックスと検索クエリで異るようです。
ちなみに、日付テキストボックスはスラッシュ区切りの日付にも対応していました。
検索結果
Slack(PCアプリ版 英語表示)
調査対象ではありませんが、せっかくなので英語表示も簡単に調べました。
メッセージの区切り
日付のツールチップ
期間での検索
検索クエリ、日付テキストボックスのフォーマットは日本語表示と同じYYYY-MM-DD
でした。検索クエリの構文は、表示する言語によって変えない方が良いので、ISO 8601に従ったYYYY-MM-DD
形式を採用したのかもしれません。
Discord(日本語表示)
テキストチャンネル
日付表記は混在していました。メッセージの日付がスラッシュ区切りなのは、できるだけスペースを使わないようにするためでしょうか。
Line(PC版)
トーク一覧
Twitter(日本語表示)
タイムライン
M月D日
タイムラインの詳細
YYYY年M月D日
時間、日付の順番で表示されていました。
Twitter(英語表示)
タイムラインの詳細
英語版も「時間、日付」の順番で表示されていました。英語の場合「時間、日付」の順番で表すのが一般的のようなので、これに従っている可能性が高いです。そして日本語表示でも、これに引っ張られて(システムの都合?)「時間、日付」の順番で表示されているのかもしれません。
一方、英語の場合、日付の順番としては、一般に「時間」→「曜日」→「日付」→「年」の順に示します。そしてそれぞれをカンマで区切り、丸括弧は使いません。
Qiita
記事の一覧画面
記事の詳細画面
記事のコメント
YYYY-MM-DD
編集履歴
下書き保存
考察
結構混在しています。
ゼロ埋めの年月日を使いつつ、一覧画面で記事は日付までしか、コメントは日時まで表示。
そして編集履歴は年月日を使った表記で"JST"も付与している。
Zenn
Articles一覧画面
記事詳細画面
一覧画面と詳細画面で、日付表記が異なっていました。
Zaim
履歴画面(日ごとタブ)
分析(日ごとの比較)
分析(月ごとの比較)
入力
Zaimの日付テキストボックスは、ハイフン区切りやスラッシュ区切りの日付も入力できました。
最近の入力
MoneyForward
ホーム画面
家計画面
- 集計期間:
YYYY/MM/DD - YYYY/MM/DD
- 一覧の日付:
MM/DD(aaa)
- 一覧の日付テキストボックス(インライン編集):
YYYY/MM/DD
Google Analytics(日本語表示)
ユーザサマリ
Google Analsistics(英語表示)
期間指定
Windowsの設定アプリ
時刻と言語 > 日付と時刻
調査してみた感想
- 10個中8個のアプリで「漢字表記」と「区切り表記」が混在していました。ただそれは、レイアウトの制約や視認性、入力のしやすさを考慮した上で、あえて混在させているのかもしれません。また、今までアプリを使っていて、日付表記が混在していることには気づかなかったので、日付表記が混在していることは、さほど気にすることはないのかもしれません。
- ほとんどのアプリで、以下の日付表記の混在はありませんでした。
- 「区切り表記」の区切り文字の混在(例外:Zennは
YYYY-MM-DD
とYYYY.MM.DD
が混在していた)
-
YYYY/MM/DD
とYYYY/M/D
など、同じ表記でのゼロ埋めありとなしの混在
- ほとんどのアプリで、「漢字表記」はゼロ埋めなしでした(例外:Qiita, Zaimはゼロ埋めありの「漢字表記」だった)。
- ほとんどのアプリで、「区切り表記」はゼロ埋めありでした(例外:Lineは
M.D(aaa)
で、ゼロ埋めなしだった)。
- 多言語化対応しているアプリかどうかで、日付表記の考え方が異なるように見えました。たとえばtwitterは日本語表示でも「時間、日付」の順番で表示されます。日本語表示では「日付、時間」の順番に表示するのが自然です。多言語化対応のコストを減らすため、どの言語でも「時間、日付」順番で表示しているのかもしれません。
- 曜日を表示するかどうかは、コンテキストによって決まるので、一般化するのは難しそうです。ただ曜日を表示しても情報量は増えないので、迷ったら「曜日を表示しない」のでも良いかもしれません。
- 日付テキストボックスは、表示している日付表記とは別の日付表記もサポートした方が便利そうです。たとえばSlackの日付テキストボックスだと
YYYY-MM-DD
形式で表示していますが、YYYY/MM/DD
形式でも入力できます。
- 一覧で日付を表示する場合は、「漢字表記」より「区切り表記」の方が見やすいように感じました(ZaimとMoneyForwardの比較)。「漢字表記」の場合は、数字より「月」や「日」が目立っていて、日付が連続していることが「区切り表記」より分かりづらかったです。
まとめ
- 「区切り表記」の区切り文字の混在(例外:Zennは
YYYY-MM-DD
とYYYY.MM.DD
が混在していた) -
YYYY/MM/DD
とYYYY/M/D
など、同じ表記でのゼロ埋めありとなしの混在
M.D(aaa)
で、ゼロ埋めなしだった)。YYYY-MM-DD
形式で表示していますが、YYYY/MM/DD
形式でも入力できます。冒頭の「日付表記を何にするか?」の答えですが、以下のルールを守った上で、アプリの性質や状況に応じて選ぶのが良いと思います。
- 一覧で日付を表示する場合は、「区切り表記のゼロ埋めあり」(例:
YYYY/MM/DD
)にして、見やすくする - 日付テキストボックスは、「区切り表記のゼロ埋めあり」にして、入力しやすくする
- 漢字表記の場合はゼロ埋めなし(例:
YYYY年M月D日
) - アプリ内で「区切り表記」の区切り文字を混在させない(例:
YYYY-MM-DD
とYYYY/MM/DD
)
補足
一覧での日付表記の比較
一覧での日付を表示する場合、M月D日
, MM/DD
, M/D
のどれが見やすいかをExcelで確認してみました。
MM/DD
が最も見やすいと感じるのですが、皆さんはいかがでしょうか?
スマホアプリでの日付表記
今回はPC版アプリに絞って調査しました。
スマホの場合PCと比較して、画面サイズが小さく、入力しづらいです。したがって、同じアプリの同じ画面でも、PC版とスマホ版で日付表記が変わります。
下図は、Android版Slackアプリのメッセージ画面です。メッセージの区切りには曜日が表示されていませんが、PC版アプリには曜日が表示されていました。
Author And Source
この問題について(PC版アプリ(Webアプリを含む)の日付表記を調査しました), 我々は、より多くの情報をここで見つけました https://qiita.com/yuji38kwmt/items/56e1696439707ffa2125著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .