日本と韓国の配送データを一つの一覧に集めると、同じ「09:00」が同じ瞬間とは限りません。この記事では、倉庫イベントの入力で UTC オフセットを必須にし、比較用の時刻と元の文字列を一緒に残す小さな Python 例を紹介します。実在の配送会社 API や顧客データを使うものではありません。
入力契約を小さく決める
この例で受け付ける形式は YYYY-MM-DDTHH:MM:SS と Z、または数値オフセットの組み合わせだけです。日付だけ、秒のない文字列、オフセットのない日時は受け付けません。Python が解釈できる全形式を受け付けるのではなく、この用途で合意した入力だけを通します。実在しない日付の検査は datetime に任せます。
元の値を残して UTC にそろえる
UTC への変換は比較のためです。元の文字列を消すと、提供元がどのオフセットを付けたのか後から確認できなくなります。戻り値には original と utc を並べます。実運用では提供元と受信時刻も別の項目として持つ必要があります。
from datetime import datetime, timezone
import re
def normalize_event(raw):
if not isinstance(raw, str) or not re.fullmatch(
r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:Z|[+-]\d{2}:\d{2})', raw
):
raise ValueError('explicit offset and seconds required')
parsed = datetime.fromisoformat(raw.replace('Z', '+00:00'))
if parsed.utcoffset() is None:
raise ValueError('offset required')
return {'original': raw, 'utc': parsed.astimezone(timezone.utc).isoformat()}
print(normalize_event("2026-10-28T09:00:00+09:00"))
# {'original': '2026-10-28T09:00:00+09:00',
# 'utc': '2026-10-28T00:00:00+00:00'}
同じ瞬間と同じ表示を区別する
+09:00 の 09:00 と Z の 00:00 は同じ瞬間として比較できます。一方、+09:00 の 09:00 と +10:00 の 09:00 は別の瞬間です。入力にオフセットがなければ、国名や倉庫名から勝手に補わず確認待ちにします。
実行確認では、同一瞬間、元文字列の保持、オフセット欠落、不正日付、日付のみ、文字列以外、異なるオフセット、秒欠落の 8 ケースを確認しました。コードは標準ライブラリのみを使用します。
この例で解決しないこと
数値オフセットは地域のタイムゾーン名ではありません。夏時間を含む将来の営業日時を計算するものでもありません。また、オフセット付き入力であっても、提供元の時計が正しかったことまでは証明できません。イベント発生時刻と受信時刻、到着の事実とデータ受信の事実も区別する必要があります。
Python datetime の公式説明を参照しました。日本から韓国へのサービス背景は김빠른（Kimfast）の日本配送案内で確認できます。著者は김빠른関連業務を担当し、AI を執筆補助に使用しました。上記は架空の設計例で、稼働中の内部システムを説明したものではありません。