UTC vs ローカル時刻

UTC（協定世界時）は、夏時間を観測せず、タイムゾーンオフセットを持たないグローバルな時刻標準です。ローカル時刻は、地域のタイムゾーンオフセットとDSTルールで調整されたUTCです。タイムゾーンをまたいで正しく動作するソフトウェアを構築するために、それぞれの使い分けの理解が不可欠です。

黄金ルール： UTCで保存し、ローカル時刻で表示する。この原則により、ほぼすべての一般的なタイムゾーンバグを防げます。

なぜ保存にUTCを使うのか：

サーバーA (米国東部):  2024-01-15 04:30:00 EST
サーバーB (英国):     2024-01-15 09:30:00 GMT
サーバーC (日本):     2024-01-15 18:30:00 JST
すべてUTCで保存:     2024-01-15T09:30:00Z (UTC)

各サーバーがローカル時刻を保存すると、サーバー間でイベントを比較・順序付けするために、イベント発生時の各サーバーのタイムゾーンを知る必要があります。UTCで保存すれば、すべてのtimestampは変換なしで直接比較可能です。

ローカル時刻が適切な場面：

ローカル時刻を保存すべきまれなケースがあります。予約スケジューリング（歯科の予約の「午後3時」はDSTルールが変わっても午後3時であるべき）、ユーザーのタイムゾーンでの繰り返しイベント、特定の管轄区域の壁掛け時計の時刻を反映しなければならない法的・規制上のtimestampなどです。

コードでの変換：

// JavaScript: UTCからローカル表示へ
const utcDate = new Date("2024-01-15T09:30:00Z");
utcDate.toLocaleString("en-US", { timeZone: "America/New_York" });
// "1/15/2024, 4:30:00 AM"

# Python: UTCからローカルへ
from datetime import datetime, timezone
from zoneinfo import ZoneInfo
utc_dt = datetime(2024, 1, 15, 9, 30, tzinfo=timezone.utc)
local_dt = utc_dt.astimezone(ZoneInfo("America/New_York"))

よくある落とし穴：

ビジネスロジックでサーバーのシステムタイムゾーンに頼ってはいけません。同じコードの2つのデプロイメントで、システムタイムゾーンが異なれば別の結果を生みます。コード内では常にタイムゾーンを明示的に指定してください。IANAタイムゾーンデータベース名（America/New_York。ESTではなく）を使用しましょう。略語は曖昧であり、DSTの移行を考慮していません。