プログラミングで日付を扱う際、「C# 日付 フォーマット」の仕様を理解しておくと、出力・表示・パースの自由度が飛躍的に上がります。標準フォーマットからカスタムフォーマット、時刻帯や文化依存表現まで幅広く解説します。実際に使えるコード例とともに、間違いやすいポイントにも触れているので、C#による日時操作に自信がない方でも一通り理解できる内容となっています。最新情報をもとに説明しますので、すぐに実践できます。
C# 日付 フォーマットの基本とは
C#における日付フォーマットは、標準フォーマット指定子とカスタムフォーマット指定子という二つの種類に分かれます。どちらも DateTime構造体または DateTimeOffset構造体の ToString メソッドなどで使用されます。標準指定子は一文字で日付と時刻の表示パターンを簡潔に指定でき、文化(Locale)に依存するため、環境設定によって出力が異なることがあります。最新環境では .NET Core や .NETのバージョンで挙動が若干異なる点にも注意が必要です。
標準フォーマット指定子とは
標準フォーマット指定子は「d」「D」「f」「F」「g」「G」「s」「u」「o」「r」など、ひと文字でパターンを指定できるものです。例えば「d」は短い日付のみ、「D」は長い日付表記、「o」はISO 8601準拠のラウンドトリップフォーマットなどです。それぞれ文化依存の表現が適用され、出力結果は環境のカルチャ設定に左右されます。
カスタムフォーマット指定子とは
カスタムフォーマット指定子を使えば「yyyy」「MM」「dd」「HH」「mm」「ss」「fff」「zzz」などを組み合わせて自由に日時表記を作成できます。文字列中の「MM」は月、「mm」は分、「dd」は日など、目的に応じて使い分けが重要です。区切り文字として「/」や「:」を使う場合、それらはロケール(文化設定)により置き換えられることがありますので、特定文字を出したい場合はクオートで囲むなどの手法が有効です。
文化依存とロケールの影響
文化(Locale)は日付と時刻の区切り文字や曜日／月の名称、AM/PM表記などに影響します。例えば日本の文化設定(ja-JP)では「年/月/日」「午前/午後」などが一般的です。文化を明示的に指定せずに標準指定子やカスタム指定子を使うと、実行環境の文化設定に応じた表記が出力されます。統一した形式が必要な場合は CultureInfo を指定する方法を使います。
標準フォーマット指定子の具体的な使い方
標準フォーマット指定子を使えば、コードが簡潔になるだけでなく、文化依存の表現を一発で適用できます。ここでは代表的な指定子とその用途、出力例を紹介します。標準指定子を覚えておくとフォーマット変換が速くなります。
よく使われる指定子一覧
- 「d」：短い日付 (例：2026/6/11など)
- 「D」：長い日付 (曜日と月の名称を含む)
- 「t」：短い時刻 (時間と分のみ)
- 「T」：長い時刻 (時間・分・秒)
- 「g」「G」：日付と時刻を組み合わせた形式 (環境によって異なる)
- 「s」：Sortable形式、タイムゾーンなしの ISO 形式に近いもの
- 「u」：Universal sortable、UTCベースのソート可能形式
- 「o」または「O」：Round-trip形式で時刻とタイムゾーン情報を含む ISO 8601 準拠形式
- 「r」または「R」：RFC1123形式、GMT表記
例と比べて理解する標準指定子
たとえば現在日時を取得して以下のように表示できます：
DateTime now = DateTime.Now;
now.ToString(“d”) → 短い日付のみ表示される。
now.ToString(“D”) → 長い日付表現「曜日 月日 年」の形。
now.ToString(“o”) → 2026-06-11T12:34:56.1234567+09:00 のようにタイムゾーン情報付きの ISO 表現。
標準指定子を使う際の注意点
標準指定子は環境のカルチャ依存性が高いため、表示結果が予期しない形式になることがあります。たとえば日本で「d」を使うと「yyyy/MM/dd」が普通ですが、英語圏では「MM/dd/yyyy」になることがあります。また「o」指定子では DateTime.Kind プロパティが UTC／Local／Unspecified のどれかによって末尾が “Z” になるかオフセット付きになるかが変わります。
カスタムフォーマット指定子で自由にフォーマットを作成する方法
標準指定子で満足できない場合、カスタムフォーマット指定子を使って自由に組み合わせた日時文字列をつくれます。先ほど少し触れましたが、書式中の大文字小文字、先行ゼロの有無、タイムゾーンとミリ秒や末尾の「K」などを使い分けることでニーズにぴったりの表記が可能となります。
主なカスタム指定子の種類と意味
- yyyy：4桁の年
- yy：2桁の年
- MM：2桁の月（先行ゼロあり）
- M：1桁月も可
- dd：2桁日
- d：1桁日も可
- HH：24時間制の時
- hh：12時間制の時
- mm：分
- ss：秒
- fff：ミリ秒
- z、zz、zzz：UTCオフセット（例＋09、＋09:00など）
- K：DateTimeOffset のオフセットまたは DateTime.Kind に応じた表記（UTCならZなど）
時刻帯やUTCとの組み合わせ
DateTimeOffsetを使えば、タイムゾーンオフセットを文字列内に含めた出力ができます。たとえば「zzz」を使うと「+09:00」のような表記になります。「K」指定子は DateTimeOffset の場合「zzz」と同じ挙動となり、DateTime の場合は Kind によって「Z」かオフセット付かが決まります。オフセットを明示する場合、ToString メソッドにカスタム書式と CultureInfo を一緒に指定する方法が安定した結果を出す密かな鍵です。
カスタム指定子を使った具体例
次のコード例で理解が深まります：
var dto = DateTimeOffset.Now;
dto.ToString(“yyyy/MM/dd HH:mm:ss zzz”) → 2026/06/11 14:23:45 +09:00 のような形式。
また UTC 時刻を「yyyy-MM-ddTHH:mm:ssK」とすると「Z」が末尾につくことになります。
ミリ秒まで含めたい場合は「yyyy-MM-ddTHH:mm:ss.fffK」などを使います。
よく使うパターン集：実務で役立つフォーマット
日付表示やログ出力、API連携などといった実務では決まったフォーマットが複数頻出します。ここではその中でも実践的なパターンを用途別にまとめ、コード例と出力例を示します。コピペで使えるので即戦力になります。
日付だけ表示したいケース
年月日だけを表示したい場合の典型パターンを紹介します。
- 「yyyy-MM-dd」：ISO準拠・ソート可能形式
- 「yyyy/MM/dd」：日本やアジア圏で一般的な区切り
- 「yyyy年MM月dd日」：日本語表記
- 「yy/MM/dd」：省略年・短い形式
コード例：
DateTime.Now.ToString(“yyyy-MM-dd”)
→ 2026-06-11
DateTime.Now.ToString(“yyyy年MM月dd日”)
→ 2026年06月11日
時刻を含めるパターン
時間まで必要な場合の代表例です。
- 24時間制「yyyy-MM-dd HH:mm:ss」：ログやデータベース用
- 12時間制「yyyy-MM-dd hh:mm tt」：ユーザー向けUI
- ミリ秒まで含める「yyyy-MM-dd HH:mm:ss.fff」
- 時間・分のみ「HH:mm」あるいは「hh:mm tt」
例：
DateTime.Now.ToString(“yyyy-MM-dd HH:mm:ss”) → 2026-06-11 14:23:45
ISO 8601 / UTC / 世界共通形式が必要なケース
API連携や保存・交換用に世界で一意になる形式を使うなら以下が定番です：
- 「o」標準指定子：より完全な ISO 8601 表現、UTC またはオフセット付き
- 「yyyy-MM-ddTHH:mm:ssK」：Z やオフセット付き
- 「s」標準指定子＋手動で Z を付ける形式：ミリ秒以外省略したい時など
例：
DateTime.UtcNow.ToString(“o”) → 2026-06-11T05:23:45.1234567Z
DateTimeOffset.Now.ToString(“yyyy-MM-ddTHH:mm:sszzz”) → 2026-06-11T14:23:45+09:00
パースおよび変換：文字列から日付／日付から文字列まで
フォーマット指定子を理解するだけでなく、文字列を DateTime に変換する操作（パース）も重要です。Format 指定子が期待するパターンに合致しなければ例外が出たり DateTimeStyles を使わなければ Kind 情報が失われたりします。
Parse と TryParseExact の使いどころ
文字列を自動的にパースできるものは Parse や TryParse を使いますが、曖昧な形式だと失敗することがあります。特定の書式で確実に読み込みたいなら TryParseExact や ParseExact を使い、フォーマット文字列と CultureInfo を指定することで安全に変換できます。時間帯情報やミリ秒・オフセットを含めるときは対応するフォーマット指定子を含めておきます。
DateTimeStyles と Kind の関係
DateTime 型には Kind プロパティがあり、Utc／Local／Unspecified のいずれかです。ISO 8601 の o 指定子などを使う場合、この Kind の設定により出力末尾に Z が付くか、オフセットが出るかなどが変わります。また ParseExact のときに DateTimeStyles.RoundtripKind を指定すると、文字列から復元するときに Kind を保持する挙動がサポートされています。
文化設定ありとなしの変換の違い
CultureInfo を指定することで、日付と時刻、曜日・月の名称、区切り文字が文化に応じたものか、または一律同じ形式かを制御できます。たとえば invariant culture を使うと、固定で英語圏や ISO 8601 準拠形式になるので、複数地域で動かすアプリや API で特に重宝します。
よくあるトラブルとその対処法
実際に C# 日付 フォーマット を使っているとき、意図しない表示になることがあります。そうしたトラブル事例と回避策を知っておくことで、安心してフォーマット変換が行えます。
「MM」と「mm」の混同
「MM」は月、「mm」は分を表します。間違えると時間表示がおかしくなります。カスタムフォーマット指定子の中で区別は大文字小文字で厳密に行われ、環境による違いはありません。コード例を試して確認することが大事です。
区切り文字が意図と違うものになる
「/」や「:」などは文化設定で置き換えられる記号です。意図的にスラッシュを表示したいときはクオート (‘/’) やバックスラッシュエスケープを使ってリテラルとして扱います。また CultureInfo.InvariantCulture を指定することで区切り文字を固定化できます。
時刻帯オフセットが期待と異なる
DateTime.Offset や DateTimeOffset を使うとき、Kind プロパティや現在のタイムゾーン設定が影響します。UTC 表記を明示したいなら DateTime.UtcNow を使用し、ToString(“o”) や ToString(“yyyy-MM-ddTHH:mm:ssK”) のような指定子を使うと期待通りの Z または ±HH:mm 表記になります。
ParseExactが失敗する主な原因
文字列とフォーマット形式が完全に一致していない、文化設定が異なる、時間部分や区切り文字が異なるなどが主な原因です。TryParseExact を使ってエラーを防ぎ、文化情報やフォーマットを明示するように設計すると堅牢性が高まります。
まとめ
C#で日付をフォーマット変換するには、標準フォーマットとカスタムフォーマット指定子を理解し、用途に応じて使い分けることが肝心です。標準指定子で簡潔に表現できるシーン、カスタム指定子で自由に整形するシーンを見極めましょう。文化設定や時間帯、DateTime.Kind の影響を無視すると意図と異なる出力になることがあるので注意します。今回紹介したパターンを使えば、読みやすく・一貫性のある時刻表示が可能になります。
コメント