閉じる

【Python】タイムゾーン入門:zoneinfoで安全に日時変換する方法

Pythonで日時を扱うとき、タイムゾーンを正しく扱えるかどうかは、障害やバグを未然に防げるかどうかに直結します。

とくにWebアプリやログ解析など、国や地域をまたいでデータを扱う場合は、zoneinfoを使った「安全なタイムゾーン処理」が必須です。

この記事では、Python 3.9以降で標準搭載されたzoneinfoを中心に、基本から実践的なパターン、既存コードの改善方法まで詳しく解説します。

Pythonのタイムゾーン基礎知識

タイムゾーンとは何か

タイムゾーンとは、地球上の「同じ標準時刻を共有する地域」のことです。

技術的には、「協定世界時(UTC)からの時刻オフセットと、その地域でのサマータイムなどのルール」で定義されます。

たとえば、よく使われるタイムゾーンには次のようなものがあります。

タイムゾーンID通常のUTCオフセット代表的な地域
UTC+00:00世界共通の基準時刻
Asia/Tokyo+09:00日本
Europe/London+00:00 or +01:00イギリス(サマータイム有)
America/New_York-05:00 or -04:00米国東海岸(サマータイム有)

重要なポイントは、タイムゾーンは単なる「オフセット値」ではなく「ID+過去から未来までのルールの集合」だということです。

サマータイムや歴史的な時差変更を正しく扱うには、このルール情報が不可欠になります。

サマータイム(DST)とその落とし穴

サマータイム(Daylight Saving Time, DST)は、夏の間だけ時計を1時間進める制度です。

ヨーロッパや北米の多くの地域で採用されており、技術的には次の2つの問題を引き起こします。

1つ目は、「存在しない時刻」が発生することです。

時計を1時間進めるとき、その1時間分のローカル時刻はカレンダー上には現れません。

たとえば、ある地域で2:00〜3:00に時計を1時間進める場合、「2:30」という時刻はその年には存在しないことになります。

2つ目は、「同じローカル時刻が2回現れる」ことです。

サマータイムを終了するとき、時計を1時間戻すため、たとえば1:30〜2:00の時刻が2回繰り返されます。

これにより、「ローカル時刻だけでは一意に時刻を特定できない」という問題が生じます。

このように、サマータイムを正しく扱うには、「その地域のタイムゾーンルールを理解しているライブラリ」に任せることが重要です。

自前でオフセットを足し引きする実装は非常に危険です。

よくある間違い

Pythonでタイムゾーンを扱うとき、よくある間違いはいくつかパターンがあります。

1つ目は、naiveなdatetime(タイムゾーン情報を持たないdatetime)をそのまま使い続けてしまうことです。

naiveなdatetimeは、同じ値が「日本時間なのかニューヨーク時間なのか」判断できません。

ログやDBに保存したあとで、どのタイムゾーンを前提にしていたかわからなくなることが頻発します。

2つ目は、固定オフセットでタイムゾーンを表現してしまうことです。

たとえばUTC+9だからといってtimedelta(hours=9)を足すだけでは、サマータイムや歴史的な変更をまったく考慮できません。

特に海外向けサービスでは、「UTC+9のはずが、その年の一部期間だけUTC+8」といった状況が普通に存在します。

3つ目は、独自ロジックでサマータイムの判定を実装してしまうことです。

サマータイムの開始・終了ルールは、年や国によってたびたび変更されます。

自前実装はほぼ確実にメンテナンスできなくなり、過去データの解釈も破綻します。

必ずIANAタイムゾーンデータベースを利用するライブラリに任せるのが安全です。

zoneinfoの基本と使い方

Python標準ライブラリzoneinfoとは

Python 3.9から、標準ライブラリにzoneinfoモジュールが追加されました。

これはIANA Time Zone Databaseを利用して、世界中のタイムゾーンルールを扱えるモジュールです。

以前はpytzなどの外部ライブラリが広く使われていましたが、zoneinfoの登場により、標準ライブラリだけで高品質なタイムゾーン処理が可能になりました。

zoneinfoを使うと次のようなメリットがあります。

  • IANA形式のタイムゾーンID(例: "Asia/Tokyo")をそのまま利用できる
  • サマータイムや過去の時差変更を自動で考慮してくれる
  • OSにインストールされたタイムゾーンデータを活用できる
  • Pythonのdatetimeモジュールと自然に連携できる

基本的には、zoneinfo.ZoneInfo("Asia/Tokyo")のようにタイムゾーンオブジェクトを作り、それをdatetimeに紐づけて使います。

zoneinfo.ZoneInfoでタイムゾーンを指定する方法

zoneinfoを使ってタイムゾーンを指定する基本パターンを見ていきます。

ZoneInfoオブジェクトの生成と基本利用

Python
from datetime import datetime
from zoneinfo import ZoneInfo

# タイムゾーンオブジェクトを生成
tokyo_tz = ZoneInfo("Asia/Tokyo")
ny_tz = ZoneInfo("America/New_York")

# タイムゾーン付き(aware)なdatetimeを生成
dt_tokyo = datetime(2024, 5, 1, 10, 0, 0, tzinfo=tokyo_tz)
dt_ny = datetime(2024, 5, 1, 10, 0, 0, tzinfo=ny_tz)

print("Tokyo:", dt_tokyo)
print("New York:", dt_ny)
print("NY in UTC offset:", dt_ny.utcoffset())
実行結果
Tokyo: 2024-05-01 10:00:00+09:00
New York: 2024-05-01 10:00:00-04:00
NY in UTC offset: -1 day, 20:00:00

ここで生成したdt_tokyodt_nyは、タイムゾーン情報を持ったawareなdatetimeです。

utcoffset()を呼ぶことで、その日時点でのUTCからのオフセットを取得できます。

now()でローカルタイムゾーンを含むdatetimeを作る

ローカルマシンのタイムゾーンを前提に現在時刻を取得する場合は、次のようにdatetime.now()tz=ZoneInfo(...)を渡します。

Python
from datetime import datetime
from zoneinfo import ZoneInfo

# 現在の東京時間を取得
now_tokyo = datetime.now(ZoneInfo("Asia/Tokyo"))

# 現在のニューヨーク時間を取得
now_ny = datetime.now(ZoneInfo("America/New_York"))

print("Now in Tokyo:", now_tokyo)
print("Now in New York:", now_ny)
実行結果
Now in Tokyo: 2025-12-20 19:23:45.123456+09:00
Now in New York: 2025-12-20 05:23:45.234567-05:00

このように、最初からタイムゾーンを指定してdatetimeを生成することで、naiveなdatetimeを極力発生させない設計が可能になります。

ローカルタイムからUTCへ安全に変換する方法

システム内部では、できる限りUTCで日時を管理するのがベストプラクティスです。

そのため、ローカルタイムからUTCへの変換方法を押さえておくことが重要です。

ローカルタイム(特定タイムゾーン)をUTCへ変換

Python
from datetime import datetime
from zoneinfo import ZoneInfo

# 2024年5月1日10:00の東京時間を表すdatetime
dt_tokyo = datetime(2024, 5, 1, 10, 0, 0, tzinfo=ZoneInfo("Asia/Tokyo"))

# UTCに変換
dt_utc = dt_tokyo.astimezone(ZoneInfo("UTC"))

print("Tokyo time:", dt_tokyo)
print("UTC time  :", dt_utc)
実行結果
Tokyo time: 2024-05-01 10:00:00+09:00
UTC time  : 2024-05-01 01:00:00+00:00

astimezone()は、元のdatetimeがどのタイムゾーンに属しているかを理解したうえで、指定したタイムゾーン(ここではUTC)の時刻に変換します。

このとき、サマータイムや歴史的なオフセット変更も自動で考慮されます。

naiveなローカル時刻を安全にUTCへ変換するには

もしすでにnaiveなdatetimeがあり、それが「ローカルタイム」だとわかっている場合でも、直接UTCだとみなしてはいけません

その地域のタイムゾーンを明示的に付与したうえで、UTCへ変換する必要があります。

Python
from datetime import datetime
from zoneinfo import ZoneInfo

# これはタイムゾーン情報のない naive datetime
naive_local = datetime(2024, 5, 1, 10, 0, 0)

# これが「東京時間」であると事前にわかっているケース
local_with_tz = naive_local.replace(tzinfo=ZoneInfo("Asia/Tokyo"))

# UTCに変換
dt_utc = local_with_tz.astimezone(ZoneInfo("UTC"))

print("Naive local:", naive_local)
print("With tz    :", local_with_tz)
print("As UTC     :", dt_utc)
実行結果
Naive local: 2024-05-01 10:00:00
With tz    : 2024-05-01 10:00:00+09:00
As UTC     : 2024-05-01 01:00:00+00:00

「実はどのタイムゾーンなのか不明なnaive datetime」が混ざっているコードは、後述するリファクタリングの対象になります。

UTCから特定タイムゾーン(例: Asia/Tokyo)へ変換する方法

外部APIやDBではUTCで日時を保存しておき、ユーザーに表示するときだけローカルタイムに変換するのが鉄則です。

その際のコードパターンを見ていきます。

Python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

# UTCの現在時刻を取得 (tzinfo=UTC 付きで生成)
now_utc = datetime.now(timezone.utc)

# UTCを東京時間とニューヨーク時間に変換
now_tokyo = now_utc.astimezone(ZoneInfo("Asia/Tokyo"))
now_ny = now_utc.astimezone(ZoneInfo("America/New_York"))

print("UTC        :", now_utc)
print("Tokyo time :", now_tokyo)
print("New York   :", now_ny)
実行結果
UTC        : 2025-12-20 10:23:45.345678+00:00
Tokyo time : 2025-12-20 19:23:45.345678+09:00
New York   : 2025-12-20 05:23:45.345678-05:00

ここで重要なのは、「UTCのdatetimeにはtimezone.utcを明示的に付与する」ことです。

これにより、コードを読む人もコンピュータも「この値はUTCである」とすぐに理解できます。

実践的な日時変換パターン

文字列からタイムゾーン付きdatetimeを生成する方法

外部から受け取る日時は、多くの場合文字列形式です。

この文字列を、適切なタイムゾーン付きdatetimeに変換するパターンを見ていきます。

1. タイムゾーン情報を含まない文字列 + 別途タイムゾーンを指定

Python
from datetime import datetime
from zoneinfo import ZoneInfo

# ユーザー入力などで受け取った日時文字列 (タイムゾーン情報なし)
s = "2024-05-01 10:00"

# 1) 文字列を naive datetime にパース
dt_naive = datetime.strptime(s, "%Y-%m-%d %H:%M")

# 2) これは「東京時間」として扱うことが仕様で決まっているとする
dt_tokyo = dt_naive.replace(tzinfo=ZoneInfo("Asia/Tokyo"))

# 3) UTCに変換してDB保存用にする
dt_utc = dt_tokyo.astimezone(ZoneInfo("UTC"))

print("Parsed naive  :", dt_naive)
print("As Tokyo      :", dt_tokyo)
print("As UTC for DB :", dt_utc)
実行結果
Parsed naive  : 2024-05-01 10:00:00
As Tokyo      : 2024-05-01 10:00:00+09:00
As UTC for DB : 2024-05-01 01:00:00+00:00

このように、「どのタイムゾーンとして解釈するか」をビジネスロジックとして明示することが大切です。

2. ISO 8601形式など、UTCオフセットを含んだ文字列の場合

ISO 8601形式(例: "2024-05-01T10:00:00+09:00")のように、UTCオフセットが含まれている文字列であれば、Python標準のfromisoformat()が便利です。

Python
from datetime import datetime

# UTCオフセット入りのISO 8601文字列
s = "2024-05-01T10:00:00+09:00"

dt = datetime.fromisoformat(s)

print("Parsed datetime:", dt)
print("tzinfo         :", dt.tzinfo)
print("UTC time       :", dt.astimezone(datetime.utcfromtimestamp(0).tzinfo or None))
実行結果
Parsed datetime: 2024-05-01 10:00:00+09:00
tzinfo         : UTC+09:00
UTC time       : 2024-05-01 01:00:00+00:00

なお、この場合のtzinfo固定オフセットとなるため、「Asia/Tokyo」などのIANAタイムゾーンIDとは異なります。

サマータイムなどのルールは含まれていません。

継続的な処理にはZoneInfoへの変換を検討します。

サマータイムを考慮した日時計算のポイント

サマータイムがあるタイムゾーンで日時計算をする際は、「何を基準に加減算するか」が重要です。

日付ベースの計算はローカルタイムで、時刻ベースの計算はUTCで

たとえば「毎日9:00に通知を出す」というような日付ベースのロジックは、ユーザーのローカルタイムゾーンで扱うのが自然です。

一方、「24時間後にトークンを失効させる」という時間ベースのロジックは、UTCで計算するのが安全です。

Python
from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo

# サマータイムのあるタイムゾーン例 (ニューヨーク)
ny_tz = ZoneInfo("America/New_York")

# 2024年3月10日 1:30 (サマータイム開始日の例)
dt_ny = datetime(2024, 3, 10, 1, 30, tzinfo=ny_tz)
print("NY local:", dt_ny)

# 「24時間後」をローカルタイムで考える (一旦UTCに変換してから計算するのが安全)
dt_utc = dt_ny.astimezone(timezone.utc)
dt_utc_plus_24h = dt_utc + timedelta(hours=24)
dt_ny_plus_24h = dt_utc_plus_24h.astimezone(ny_tz)

print("NY +24h (via UTC):", dt_ny_plus_24h)
実行結果
NY local: 2024-03-10 01:30:00-05:00
NY +24h (via UTC): 2024-03-11 02:30:00-04:00

サマータイムが開始されると、その日だけは「1日が23時間」になる場合があります。

このようなケースでも、UTCで加算してからローカルに戻すことで、サマータイムを正しく越えられます。

ログやDBでのUTC管理と表示時のタイムゾーン変換

システム設計の基本として、ログやDBにはUTCで保存し、表示時にのみタイムゾーン変換するというスタイルがあります。

DB保存時: ローカル→UTC

Python
from datetime import datetime
from zoneinfo import ZoneInfo

# ユーザーが東京でフォームに入力した日時 (例: "2024-05-01 10:00")
input_str = "2024-05-01 10:00"

# 1) パースして東京時間として解釈
dt_local = datetime.strptime(input_str, "%Y-%m-%d %H:%M").replace(
    tzinfo=ZoneInfo("Asia/Tokyo")
)

# 2) UTCに変換してDBに保存
dt_utc_for_db = dt_local.astimezone(ZoneInfo("UTC"))

print("Local(Tokyo):", dt_local)
print("DB(UTC)     :", dt_utc_for_db.isoformat())
実行結果
Local(Tokyo): 2024-05-01 10:00:00+09:00
DB(UTC)     : 2024-05-01T01:00:00+00:00

画面表示時: UTC→ユーザータイムゾーン

Python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

# DBから取り出したUTC日時文字列
db_value = "2024-05-01T01:00:00+00:00"

# UTCのaware datetimeとして復元
dt_utc = datetime.fromisoformat(db_value)

# ユーザーのタイムゾーン(例: ユーザープロファイルから取得)
user_tz = ZoneInfo("Asia/Tokyo")

# 表示用ローカル時刻に変換
dt_for_display = dt_utc.astimezone(user_tz)

print("DB(UTC)       :", dt_utc)
print("User timezone :", user_tz)
print("For display   :", dt_for_display)
実行結果
DB(UTC)       : 2024-05-01 01:00:00+00:00
User timezone : zoneinfo.ZoneInfo(key='Asia/Tokyo')
For display   : 2024-05-01 10:00:00+09:00

このスタイルに統一することで、複数タイムゾーンのユーザーが混在しても、DBの整合性を保ちやすくなります

複数タイムゾーンユーザー向けの日時表示設計

世界中のユーザーを対象とするWebサービスでは、各ユーザーのタイムゾーン設定に応じて日時を表示する必要があります。

その際の設計ポイントを整理します。

1つ目は、ユーザープロファイルにタイムゾーンIDを保存することです。

IANA形式の文字列(例: "Asia/Tokyo")をそのまま持っておくと、zoneinfoで簡単に利用できます。

2つ目は、画面表示直前でのみタイムゾーン変換を行うことです。

DBやビジネスロジック層では一貫してUTCで扱い、ビュー層でastimezone(ZoneInfo(user.timezone))のように変換するのが安全です。

3つ目は、タイムゾーン名やUTCオフセットも一緒に表示することです。

たとえば「2024-05-01 10:00 (Asia/Tokyo, UTC+9)」のように表示すれば、ユーザーにとって誤解が少なくなります。

Python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

def format_for_user(dt_utc: datetime, user_tz_str: str) -> str:
    """UTC datetime をユーザーのタイムゾーンで見やすい文字列に整形する例"""
    user_tz = ZoneInfo(user_tz_str)
    dt_local = dt_utc.astimezone(user_tz)
    offset = dt_local.utcoffset()
    hours = int(offset.total_seconds() // 3600)
    minutes = int((offset.total_seconds() % 3600) // 60)
    offset_str = f"UTC{hours:+03d}:{minutes:02d}"
    # 例: "2024-05-01 10:00 (Asia/Tokyo, UTC+09:00)"
    return dt_local.strftime("%Y-%m-%d %H:%M") + f" ({user_tz_str}, {offset_str})"

# 例として現在UTCを使う
now_utc = datetime.now(timezone.utc)

print(format_for_user(now_utc, "Asia/Tokyo"))
print(format_for_user(now_utc, "America/Los_Angeles"))
実行結果
2025-12-20 19:23 (Asia/Tokyo, UTC+09:00)
2025-12-20 02:23 (America/Los_Angeles, UTC-08:00)

「UTCで一元管理し、ユーザーごとにzoneinfoで変換して表示」というスタイルを徹底することで、多言語・多地域対応の堅牢なシステムが構築できます。

既存コードの改善とベストプラクティス

timeやpytzからzoneinfoへの移行方法

既存プロジェクトでは、timeモジュールやpytzを使っているケースも多いと思います。

zoneinfoへの移行は段階的に進めると安全です。

pytzの基本パターンをzoneinfoに置き換える

pytzではlocalize()normalize()といった独自メソッドが必要でしたが、zoneinfoでは標準のdatetimeAPIに統合されています

pytzの例:

Python
# pytz を使った古いコード例
import pytz
from datetime import datetime

tz = pytz.timezone("Asia/Tokyo")
dt_naive = datetime(2024, 5, 1, 10, 0, 0)

# pytzでは localize が必要
dt_tokyo = tz.localize(dt_naive)

# UTCに変換
dt_utc = dt_tokyo.astimezone(pytz.utc)

zoneinfoでの書き換え:

Python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

tz = ZoneInfo("Asia/Tokyo")
dt_naive = datetime(2024, 5, 1, 10, 0, 0)

# zoneinfoでは tzinfo を直接指定
dt_tokyo = dt_naive.replace(tzinfo=tz)

# UTCに変換 (timezone.utc を使用)
dt_utc = dt_tokyo.astimezone(timezone.utc)

ポイントは「pytz独自のlocalize/normalizeをやめて、標準のdatetime APIだけで完結させる」ことです。

timeモジュールからの移行

time.localtime()time.gmtime()などを多用している場合も、段階的にdatetime+zoneinfoに置き換えていきます。

Python
# 古い例: timeモジュール
import time

timestamp = time.time()
local_struct = time.localtime(timestamp)
utc_struct = time.gmtime(timestamp)
Python
# 新しい例: datetime + zoneinfo
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

timestamp = datetime.now(timezone.utc).timestamp()

dt_utc = datetime.fromtimestamp(timestamp, tz=timezone.utc)
dt_local_tokyo = dt_utc.astimezone(ZoneInfo("Asia/Tokyo"))

すぐにすべてを置き換えるのが難しい場合は、まずは新しいコードからzoneinfoを採用し、既存部分は必要に応じて徐々に移行する方針も現実的です。

naiveなdatetimeを安全に扱うためのリファクタリング

naiveなdatetimeは、「どのタイムゾーン前提なのか曖昧なデータ」を生み出します。

リファクタリングのポイントは次の通りです。

  1. naive datetimeがどこから生まれているかを洗い出す
  2. それぞれを「UTC」か「特定のローカルTZ」のどちらとして扱うべきかを仕様で決める
  3. 生成時点でtzinfoを付与し、以降はaware datetimeで処理する
Python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

def parse_user_input_naive(text: str) -> datetime:
    """既存の naive な実装 (要修正)"""
    return datetime.strptime(text, "%Y-%m-%d %H:%M")

def parse_user_input_tokyo(text: str) -> datetime:
    """東京ユーザー前提に仕様を明示した安全な実装"""
    dt_naive = datetime.strptime(text, "%Y-%m-%d %H:%M")
    return dt_naive.replace(tzinfo=ZoneInfo("Asia/Tokyo"))

def get_now_utc() -> datetime:
    """常にUTCの現在時刻を返す"""
    return datetime.now(timezone.utc)

「このdatetimeは常にUTC」「このdatetimeは常にユーザーのタイムゾーン」という約束を関数レベルで明示しておくと、コード全体の安全性が格段に上がります。

タイムゾーン変換で避けるべきアンチパターン

タイムゾーン関連で特に避けるべきパターンを整理します。

固定オフセットだけで処理する

Python
# NG例: UTC+9 を固定オフセットだけで表現
from datetime import datetime, timedelta

dt_utc = datetime.utcnow()
# これはAsia/Tokyoの完全な代替にはならない
dt_tokyo_like = dt_utc + timedelta(hours=9)

このような実装は、サマータイムや将来のルール変更に対応できません。

必ずZoneInfo("Asia/Tokyo")のようにIANAタイムゾーンIDを使いましょう

naive datetime 同士を比較する

Python
# NG例: どちらもタイムゾーン不明のまま比較
from datetime import datetime

a = datetime(2024, 5, 1, 10, 0, 0)  # 実は東京時間のつもり
b = datetime(2024, 5, 1, 2, 0, 0)   # 実はUTCのつもり

print(a > b)  # 何を意味する比較か不明瞭

このような比較は、バグが発生しても気づきにくい典型例です。

比較前に両方をUTCに揃えるか、同じタイムゾーンに変換してから比較してください。

ローカルタイムをそのままDBに保存する

Python
# NG例: タイムゾーン不明のローカル時刻をそのままDBへ
created_at = datetime.now()  # tzinfo なし (環境依存)
# これをそのまま文字列化して保存してしまう

これは将来「この時刻はどの国の何時だったのか」がわからなくなります。

必ずUTCで保存し、必要に応じてタイムゾーン情報も別カラムなどで保存しましょう。

zoneinfoを使ったPython日時処理のまとめと推奨スタイル

最後に、zoneinfoを使った日時処理の推奨スタイルを整理しておきます。

  1. システム内部・DB・ログはUTCで統一する
  2. ユーザーへの表示時にのみタイムゾーン変換を行う
  3. IANAタイムゾーンID(例: “Asia/Tokyo”)をユーザープロファイルなどに保存し、ZoneInfoで利用する
  4. naive datetimeは原則禁止し、生成時に必ずtzinfoを付与する
  5. サマータイムや歴史的なオフセット変更は自分で計算せず、必ずzoneinfoに任せる
Python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

def now_utc() -> datetime:
    """UTCの現在時刻(aware)を返す"""
    return datetime.now(timezone.utc)

def from_user_input(text: str, user_tz_str: str) -> datetime:
    """ユーザー入力文字列をユーザータイムゾーンのaware datetimeに変換"""
    dt_naive = datetime.strptime(text, "%Y-%m-%d %H:%M")
    return dt_naive.replace(tzinfo=ZoneInfo(user_tz_str))

def to_db_value(dt_utc: datetime) -> str:
    """UTC datetimeをDB保存用のISO文字列に変換"""
    # ここではdt_utcが本当にUTCかどうかは呼び出し側の契約とする
    return dt_utc.isoformat()

def for_display(dt_utc: datetime, user_tz_str: str) -> str:
    """UTC datetimeをユーザータイムゾーンの表示用文字列に変換"""
    return dt_utc.astimezone(ZoneInfo(user_tz_str)).strftime("%Y-%m-%d %H:%M")
実行結果
# これらの関数を組み合わせることで、
# 「内部はUTC、表示だけユーザーTZ」というスタイルを実現できる

まとめ

zoneinfoを使うことで、Pythonは標準ライブラリだけで世界中のタイムゾーンとサマータイムを安全に扱える環境になりました。

ポイントは、システム内部とDBではUTCで一元管理し、ユーザーごとのIANAタイムゾーンIDに基づいて表示時のみ変換することです。

また、naiveなdatetimeを排除し、常にtzinfo付きのaware datetimeを使うことで、タイムゾーン起因のバグを大幅に減らせます。

既存のtimeやpytzベースのコードも、zoneinfoを前提に少しずつリファクタリングしていくことで、将来にわたって安心して運用できる日時処理基盤を整えられます。

クラウドSSLサイトシールは安心の証です。

URLをコピーしました!