日付の書式｜UIデザインポリシー整理（仮）
リーガルテックAI SaaSスタートアップ、MNTSQのプロダクトデザイナーのクボスケです。
私たちは、レバレッジの効くデザインの仕組みづくりを目指しています。この記事は、MNTSQとしてのUIデザインの基準や方針を決めていく「UIデザインポリシー整理（仮）」というプロジェクトのなかで行なわれたディスカッションをもとにまとめたものです。
このプロジェクトの主旨や運営については、初回の記事でも述べていますので、ぜひご覧ください。
それでは、今回のトピックは「日付の書式」です。
日付の書式
システムではさまざまな日付・時刻を取り扱います。ログイン日時や最終更新日などは自動で記録されますが、期限や通知の予定などはユーザーが入力します。どちらの場合でも、同じシステム内では統一した書式にする必要があります。
年月日の区切りには「/（半角スラッシュ）」を使います。曜日は必要な場合にだけ付けます。時刻は年月日とスペースで区切り、「:（半角コロン）」で時、分、秒を区切ります。時刻は24時間表記にします。月日、時刻は一桁の場合にも十の位を「0」で埋めます。順序は年、月、日、曜日、時、分、秒の順にします。時刻や秒の有無は、その場面で必要かどうかで決めます。区切り字、順序、曜日の表記は、各ロケールのユーザーにとって慣例的・合理的なものにします。
日付は基本的には絶対日付で表します。「たったいま」「1時間前」「今日」など相対日付は、通知など情報の鮮度が大事な場合に限って使います。ユーザーにとって意味のある時間の範囲にします。
データとして年は西暦で表しますが、契約書などで「X年X月X日」のように保存するものは、文字列としてそのまま扱います。
以下はやりとりの内容を一部抜粋したものです。
クボスケ：日付の書式の国際標準規格には、ISO 8601形式がありますね。“YYYYMMDD”あるいは「-（半角ハイフン）」で区切った“YYYY-MM-DD”の2通りと定められています。ただ、日本での日常的な感覚だと、「-」で区切るのはちょっといかにもシステム的な印象も受けます
ナカシマ：区切り記号は「.（ドット）」を使ったことがあります。多言語対応のサービスでした。英語だと日本語とは違う並び順が一般的ですね
kassy：世界的に年・月・日の順を採用しているサービスもありますよね。それからMicrosoft Wordのように区切りが「年月日」と「/（半角スラッシュ）」が混在しているものもあったり。年・月・日に時・分が続くと、区切りが漢字なのは違和感がありますね
クボスケ：月と日の区別がつくように、月は数字ではなくて月名やその略称（「Feb」など）にしているものも見かけますね。並び順については、他にも文化圏によって慣例的なものはけっこういろいろあるようです。あと日本だと元号表記も。JISでは元号の頭文字のアルファベット表記（「M／T／S／H／R」）の定めもあるようです
ナカシマ：ロケールごとに表示を分けることもできますね
クボスケ：月や日が1桁の場合に、十の位を0で埋めるかどうか、はどうですか。見た目の幅を揃える目的なら、等幅フォントにしないと結局ガタついちゃいますが
kassy：区切りが「年月日」の場合は0で埋めると違和感。「/」の場合は自然に感じます
クボスケ：相対日付の概念についても話しましょう。Slackなどコミュニケーションツールだと、いつの情報なのか鮮度が重要で時間の経過によって価値が変わるためなのか、「たったいま」「1分前」「1時間前」などの表記が見られます
ナカシマ：逆に正確な日付時刻を知りたい時に困ることも。通知とかは純粋なフロー情報なので相対でいいのだと思いますが
kassy：GitHubなどはレビューがメインの目的なので相対的な表記のほうが都合がいいのかも。JIRAは更新と作成のときで、意図的に日付時刻表記と相対表記を分けているみたいです。MNTSQのCLM（Contract Lifecycle Management）プロダクトでは、正確性のほうが重要な場面が多いのでは
クボスケ：曜日についてはどうしましょう
ナカシマ：一般的には、イベントなど曜日に意味があるケースもありますよね
クボスケ：MNTSQではあまり関係がなさそうですが、以前贈答品の受付・管理システムで、カレンダーに六曜を表示するようにしたことがあります。仏滅を避け、大安の日に届くようにしたいというニーズがあったので
kassy：業務用のシステムとしては、ユーザーにアクションを求める期限日などが土日にならないように、参考情報として曜日が表示されていたり、曜日で指定できたりするといいかもしれません
ナカシマ：祝日のライブラリを利用したりすれば、営業日の計算などもいい感じにできるかも
クボスケ：カレンダーやタスク管理アプリなどで、繰り返しの予定は月末のように相対的に指定できたりしますね
ナカシマ：それから、時間について12時間表記か24時間表記かという論点があります
kassy：24時間表記のほうが、混乱は少ないですよね
クボスケ：12時間表記の場合、午前／午後の表記をどうするかという論点も考慮する必要が出てきますね。「AM」なのか「a.m.」なのか、数字の前か後か、など
ナカシマ：会話的なライティングという視点だと、24時間表記はあまり慣例的ではないとも言えます。でも誤解を生まないかどうかは大事だと思います
kassy：なにがしっくりくるかは、個々のユーザーにとってさまざまではあるので、画一的に提供するところを見極めつつ、どのくらいカスタマイズ性を用意するのかも重要かも。たとえばNotionは個々のユーザー自身が柔軟に日付の表示を変更できます。ユーザーとどう向き合うかは、プロダクトのデザイン原則から導き出されるようなところも
ナカシマ：同じ業務を共有しているユーザーの間では、表示が同一であることはある程度必要だったり
クボスケ：カスタマイズできるようにするとしても、デフォルトの形式は定めておく必要がありますね。システムで管理者が設定できるとか
ナカシマ：システムとして権限とあわせて機能をもっておくことはできますね
クボスケ：あと、これはMNTSQならではかも知れませんが、契約書は和暦で書くことも多いです。西暦の日付とは別に、契約書内に記載どおりの文字列を取り扱う必要がありますね