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オブジェクトの生成と基本利用
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_tokyoやdt_nyは、タイムゾーン情報を持ったawareなdatetimeです。
utcoffset()を呼ぶことで、その日時点でのUTCからのオフセットを取得できます。
now()でローカルタイムゾーンを含むdatetimeを作る
ローカルマシンのタイムゾーンを前提に現在時刻を取得する場合は、次のようにdatetime.now()にtz=ZoneInfo(...)を渡します。
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へ変換
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へ変換する必要があります。
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で日時を保存しておき、ユーザーに表示するときだけローカルタイムに変換するのが鉄則です。
その際のコードパターンを見ていきます。
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. タイムゾーン情報を含まない文字列 + 別途タイムゾーンを指定
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()が便利です。
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で計算するのが安全です。
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
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→ユーザータイムゾーン
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)」のように表示すれば、ユーザーにとって誤解が少なくなります。
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の例:
# 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での書き換え:
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に置き換えていきます。
# 古い例: timeモジュール
import time
timestamp = time.time()
local_struct = time.localtime(timestamp)
utc_struct = time.gmtime(timestamp)
# 新しい例: 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は、「どのタイムゾーン前提なのか曖昧なデータ」を生み出します。
リファクタリングのポイントは次の通りです。
- naive datetimeがどこから生まれているかを洗い出す
- それぞれを「UTC」か「特定のローカルTZ」のどちらとして扱うべきかを仕様で決める
- 生成時点で
tzinfoを付与し、以降はaware datetimeで処理する
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は常にユーザーのタイムゾーン」という約束を関数レベルで明示しておくと、コード全体の安全性が格段に上がります。
タイムゾーン変換で避けるべきアンチパターン

タイムゾーン関連で特に避けるべきパターンを整理します。
固定オフセットだけで処理する
# 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 同士を比較する
# 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に保存する
# NG例: タイムゾーン不明のローカル時刻をそのままDBへ
created_at = datetime.now() # tzinfo なし (環境依存)
# これをそのまま文字列化して保存してしまう
これは将来「この時刻はどの国の何時だったのか」がわからなくなります。
必ずUTCで保存し、必要に応じてタイムゾーン情報も別カラムなどで保存しましょう。
zoneinfoを使ったPython日時処理のまとめと推奨スタイル

最後に、zoneinfoを使った日時処理の推奨スタイルを整理しておきます。
- システム内部・DB・ログはUTCで統一する
- ユーザーへの表示時にのみタイムゾーン変換を行う
- IANAタイムゾーンID(例: “Asia/Tokyo”)をユーザープロファイルなどに保存し、
ZoneInfoで利用する - naive datetimeは原則禁止し、生成時に必ず
tzinfoを付与する - サマータイムや歴史的なオフセット変更は自分で計算せず、必ずzoneinfoに任せる
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を前提に少しずつリファクタリングしていくことで、将来にわたって安心して運用できる日時処理基盤を整えられます。
