メインコンテンツへ
プログラミング

時刻表示フォーマットの設計 - 12 時間制と 24 時間制、ロケール対応の実装指針

12 時間制と 24 時間制 - 地域による慣習の違い

時刻表示の最も基本的な分岐点は、12 時間制 (AM/PM) と 24 時間制の選択です。アメリカ、カナダ、オーストラリア、フィリピンなどでは 12 時間制が日常的に使われ、ヨーロッパ大陸、日本、韓国、中国などでは 24 時間制が一般的です。イギリスは口語では 12 時間制を使いつつ、時刻表や公式文書では 24 時間制を採用するという二重構造を持っています。

ソフトウェア設計において重要なのは、この選択をユーザーのロケール設定に委ねることです。サーバー側で時刻を「14:30」と固定的にフォーマットすると、アメリカのユーザーには不自然に映ります。逆に「2:30 PM」と表示すると、24 時間制に慣れたユーザーは一瞬の変換コストを強いられます。ユーザーの OS やブラウザのロケール設定を尊重し、適切な形式で表示する設計が求められます。

ISO 8601 の適用範囲 - 機械向けと人間向けの使い分け

ISO 8601 (例: 2026-05-15T16:30:00+09:00) は機械間のデータ交換に最適な形式ですが、人間が読む UI にそのまま表示すべきではありません。API レスポンス、データベース格納、ログ出力には ISO 8601 を使い、画面表示時にはロケールに応じた人間可読な形式に変換するのが正しい設計です。

ただし、技術者向けのダッシュボードやデバッグ画面では ISO 8601 をそのまま表示する方が有用な場合もあります。タイムゾーンオフセットが明示されるため、異なるタイムゾーンのイベントを比較する際に曖昧さがありません。対象ユーザーが技術者か一般ユーザーかによって、表示形式の判断は変わります。

Intl.DateTimeFormat - ブラウザネイティブの国際化

JavaScript の Intl.DateTimeFormat API は、ロケールに応じた時刻フォーマットをブラウザネイティブで提供します。new Intl.DateTimeFormat('ja-JP', { hour: '2-digit', minute: '2-digit' }).format(date) は「16:30」を返し、ロケールを 'en-US' に変えれば「4:30 PM」を返します。ライブラリを追加することなく、OS の国際化データを活用できる点が最大の利点です。

注意すべきは、同じロケールでもオプションの組み合わせによって出力が変わることです。dateStyle と timeStyle を使う方法と、year/month/day/hour/minute を個別に指定する方法があり、両者を混在させるとエラーになります。また、ブラウザ間で微妙な出力差 (全角コロンと半角コロン、スペースの有無など) が存在するため、スナップショットテストには向きません。

相対時刻表示 - 「3 分前」の設計判断

SNS やチャットアプリでは「3 分前」「2 時間前」「昨日」のような相対時刻表示が一般的です。この表示は直感的ですが、設計上の判断ポイントが多数あります。「何秒前」まで表示するか (多くのサービスは 1 分未満を「たった今」と表示)、何日前から絶対時刻に切り替えるか (Twitter は 24 時間、Facebook は 7 日)、タイムゾーンをまたぐ場合の「昨日」の基準は何か、といった問題です。

Intl.RelativeTimeFormat API を使えば、ロケールに応じた相対時刻の文字列を生成できます。ただし、この API は「何単位前か」の計算自体は行わないため、現在時刻との差分から適切な単位 (秒/分/時間/日/週/月/年) を選択するロジックは自前で実装する必要があります。

エッジケース - 深夜 0 時と正午の表記

12 時間制における最大の曖昧さは、12:00 AM と 12:00 PM の解釈です。慣習的に 12:00 PM は正午、12:00 AM は深夜 0 時を指しますが、これは論理的に矛盾しています (PM = post meridiem = 正午の後、なのに正午そのものが PM)。この曖昧さを避けるため、航空業界では深夜を 00:00、正午を 12:00 と 24 時間制で表記し、アメリカの法律文書では「12:00 noon」「12:00 midnight」と明記します。

ソフトウェアでこの問題に対処する最善策は、12 時間制で表示する場合でも内部的には 24 時間制の整数 (0-23) で時刻を保持し、表示時にのみ変換することです。ユーザー入力を受け付ける場合は、12:00 AM/PM の解釈を明確にバリデーションし、テストケースに含めておくべきです。

XB!LINE

この記事は役に立ちましたか?