UTC保存の原則
取得はUTC、保存と通信はUTCまたはオフセット付き、ローカル時刻への変換は画面・帳票に出す直前の1回だけに限るという日時処理の設計原則。
- 概念URI
https://comcomponent.com/knowledge/utc-storage-principle/- 最終確認日
- 2026-08-01
- 機械可読データ
- JSON-LD
この概念が関わる関係
- UTC保存の原則はサーバー移設時の9時間ずれ事故を防ぎます。取得・保存・通信をUTCまたはオフセット付きで統一し表示直前だけ変換する原則を守れば、環境依存の暗黙変換が構造的に起きない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- UTC保存の原則はDST切替日の定期実行の多重実行・欠測を軽減します。スケジュール基準をUTC(またはDSTの無いタイムゾーン)にし、処理を冪等にし、集計キーを業務日付で持てば、DSTによる多重実行・欠測の問題が解消する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- UTC保存の原則はラウンドトリップ書式("o")を利用します。境界を文字列で越えるときはISO 8601準拠のラウンドトリップ書式"o"を使い、Kindやオフセットを保持したまま復元できるようにする / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
- UTC保存の原則はNTP(Network Time Protocol)を前提とします。複数マシンにまたがる絶対時刻としてUTC基準の値を突き合わせる場合は、そもそもマシンの時計がNTPでネットワーク上の時刻源と正しく同期されている必要がある(Windows環境ではこの同期をw32timeサービスが担う)。UTCで保存して表示直前に変換するという表現上の原則自体は、時計が同期されていなくても成り立つ / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
- UTC保存の原則はTimeProviderを利用します。テストで時刻を差し替え可能にしたい場合、発生時刻の取得はTimeProvider.GetUtcNow()に統一し、DateTime.Nowの直書きをやめる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
- SQL Serverのdatetime2型はUTC保存の原則に対する本記事の推奨です。UTCで保存する列の本体としては、精度が高く公式に新規採用が推奨されるdatetime2が本命とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
この概念を扱う記事
一次資料
このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。