日付データでずれないための基本：YYYY-MM-DD形式とタイムゾーンを実務で扱う
Webフォーム、WordPress予約投稿、CSV取り込み、自動化スクリプトで日付を扱うなら、まず分けて考えるべきものがあります。「日付だけ」なのか、「時刻つきの日時」なのか、「どの地域の時刻か」です。
2026-07-07 は見た目には分かりやすい日付ですが、それだけでは「日本時間の7月7日0時」なのか、「UTCでの7月7日」なのかまでは表しません。この違いを曖昧にしたまま保存、API送信、サーバー処理をすると、一覧画面では7月7日なのに通知は7月6日に動く、といったずれが起きます。
この記事では、Web制作、WordPress、サーバー運用、自動化でよく使う日付データの基本を、実務で確認しやすい形に整理します。
YYYY-MM-DDは「日付だけ」を表す形式として扱う- 時刻やタイムゾーンが必要な処理では、
2026-07-07T09:00:00+09:00のように明示する - WordPress、JavaScript、Python、APIでは、同じ文字列でも解釈が変わることがある
- 保存用、表示用、入力用を分けると、日付ずれを減らしやすい
前提：この記事で扱う環境
この記事では、特定のフレームワークに閉じず、実務でよく出る組み合わせを前提にします。
- Webフォーム: HTMLの
input type="date" - ブラウザ側処理: JavaScriptの
Date - 自動化スクリプト: Python 3.9以降の
zoneinfo - WordPress: 管理画面のタイムゾーン設定と投稿日時
- サーバー/API: UTC保存とローカル時刻表示の考え方
細かい挙動は実行環境やライブラリで変わるため、ここでは「どう考えると事故が減るか」を中心に説明します。
YYYY-MM-DDは「日付だけ」として扱う
YYYY-MM-DD は、誕生日、締切日、公開日、集計対象日など、時刻を必要としないデータに向いています。
たとえば、次のような値です。
2026-07-07
これは読みやすく、並べ替えもしやすい形式です。YYYYが年、MMが月、DDが日なので、文字列のままでも日付順に並びやすい利点があります。
向いている場面
YYYY-MM-DD が向いているのは、時刻よりも「日付そのもの」が意味を持つ場面です。
- キャンペーン開始日
- 請求対象日
- CSVの取引日
- タスクの期限日
- WordPress記事の公開予定日を人が確認する画面
この場合、2026-07-07 に時刻を足して無理に2026-07-07 00:00:00として扱うと、タイムゾーン変換で前日になることがあります。日付だけでよいなら、日付だけとして持つほうが安全です。
向いていない場面
一方で、実行タイミングが必要な処理では不十分です。
- 予約投稿を何時に公開するか
- メールを何時に送るか
- APIの有効期限がいつ切れるか
- サーバーログの発生時刻を比較する
この場合は日付だけでなく、時刻とタイムゾーンも必要です。
ここがポイント:
YYYY-MM-DDは便利ですが、「その日の何時か」までは決めてくれません。処理を動かす時刻が必要なら、日時として扱います。
タイムゾーンは「どの地域の時計か」を示す
タイムゾーンは、同じ瞬間をどの地域の時刻で表示するかを決める情報です。
日本時間の2026年7月7日9時は、UTCでは2026年7月7日0時です。どちらも同じ瞬間ですが、表示される時刻が違います。
日本時間: 2026-07-07 09:00:00 +09:00
UTC: 2026-07-07 00:00:00 +00:00
+09:00 はUTCより9時間進んでいることを表します。日本では夏時間がないため、実務ではAsia/Tokyoまたは+09:00をよく見ます。
UTC保存、ローカル表示がよく使われる理由
サーバーやAPIでは、保存時にUTCを使い、表示時にユーザーやサイトのタイムゾーンへ変換する設計がよく使われます。
理由はシンプルです。複数地域のユーザー、クラウドサーバー、外部APIが関わると、ローカル時刻だけでは比較しにくいからです。
たとえば、次の2つは同じ瞬間を表せます。
2026-07-07T09:00:00+09:00
2026-07-07T00:00:00Z
末尾のZはUTCを表す表記です。APIのレスポンスやログでよく出ます。
WordPressではサイト設定が表示に効く
WordPressでは、管理画面の「設定」からサイトのタイムゾーンを設定します。投稿日時、予約投稿、表示上の日付は、この設定の影響を受けます。
初心者がつまずきやすいのは、次のような分担です。
- サーバーのOSにもタイムゾーン設定がある
- WordPressにもサイトのタイムゾーン設定がある
- PHPやプラグインが別の前提で日時を扱う場合がある
- 外部APIはUTCで日時を返すことが多い
WordPressで「投稿日がずれる」「予約投稿の時刻が想定と違う」ときは、まずサイトのタイムゾーン設定を確認します。サーバー側の時刻だけを見ても、原因を取り違えることがあります。
入力・保存・表示を分けると混乱しにくい
日付データの扱いで大事なのは、1つの形式ですべてを済ませようとしないことです。
同じ「日付」でも、入力、保存、表示では目的が違います。
| 用途 | 例 | 考え方 |
|---|---|---|
| 入力 | 2026-07-07 | ユーザーが選びやすい日付形式にする |
| 保存 | 2026-07-07 または 2026-07-07T00:00:00Z | 日付だけか日時かを決めて保存する |
| API連携 | 2026-07-07T09:00:00+09:00 | 時刻とタイムゾーンを明示する |
| 表示 | 2026年7月7日 9:00 | 読者や管理者が読みやすい形に変換する |
HTMLフォームの入力例
HTMLの日付入力では、値としてYYYY-MM-DD形式を扱います。
<label for="publish-date">公開日</label>
<input id="publish-date" name="publish_date" type="date" value="2026-07-07">
フォーム上ではカレンダーUIが表示されても、送信される値は基本的に次のような文字列です。
publish_date=2026-07-07
ここで得られるのは「日付」です。予約投稿のように時刻も必要なら、別途time入力やタイムゾーンを組み合わせます。
API送信用の日時例
APIへ「日本時間の2026年7月7日9時」を送るなら、次のようにタイムゾーンを含めます。
{
"scheduled_at": "2026-07-07T09:00:00+09:00"
}
この形なら、受け取る側は「どの地域の9時か」を判断できます。2026-07-07 09:00:00だけだと、サーバーの設定やAPI仕様によって解釈が変わる余地が残ります。
JavaScriptで日付を扱うときの注意点
JavaScriptでは、Dateを使うときに日付文字列の解釈でつまずきやすくなります。
特に、YYYY-MM-DDをDateに渡したとき、それをローカルの日付として扱うつもりでも、環境や仕様上の解釈によって期待と違う表示になることがあります。
const value = "2026-07-07";
const date = new Date(value);
console.log(date.toISOString());
console.log(date.toLocaleDateString("ja-JP", { timeZone: "Asia/Tokyo" }));
このコードでは、Dateオブジェクトにした時点で「ある瞬間」として扱われます。日付だけを表示したいだけなら、無理にDateへ変換せず、文字列として検証・保存するほうが単純な場合があります。
日付だけなら文字列のまま扱う選択肢もある
たとえば、フォームで受け取った締切日を保存するだけなら、次のように形式チェックだけに留める方法があります。
const dateText = "2026-07-07";
const isDateOnly = /^\d{4}-\d{2}-\d{2}$/.test(dateText);
if (!isDateOnly) {
throw new Error("日付はYYYY-MM-DD形式で入力してください");
}
ただし、この正規表現だけでは2026-99-99のような実在しない日付までは弾けません。実務では、形式チェックと日付としての妥当性チェックを分けて考えます。
日時として扱うならタイムゾーンを入れる
通知や予約処理のように時刻が必要なら、タイムゾーンつきの文字列を使います。
const scheduledAt = "2026-07-07T09:00:00+09:00";
const date = new Date(scheduledAt);
console.log(date.toISOString());
toISOString()はUTC基準の文字列を返します。保存用にUTCへそろえたい場合には便利ですが、管理画面にそのまま出すと日本時間ではなくUTC表示になります。
Pythonではdateとdatetimeを分ける
Pythonで自動化スクリプトを書く場合は、dateとdatetimeを分けて使うと意図が明確になります。
日付だけならdatetime.date、時刻とタイムゾーンが必要ならdatetime.datetimeを使います。
YYYY-MM-DDを日付として読む
from datetime import date
value = "2026-07-07"
d = date.fromisoformat(value)
print(d)
期待される出力は次の通りです。
2026-07-07
この例では時刻を持ちません。CSVの取引日や締切日を扱うなら、このほうが分かりやすいです。
タイムゾーンつき日時を扱う
Python 3.9以降では、標準ライブラリのzoneinfoでIANAタイムゾーン名を扱えます。
from datetime import datetime
from zoneinfo import ZoneInfo
jst = ZoneInfo("Asia/Tokyo")
scheduled_at = datetime(2026, 7, 7, 9, 0, 0, tzinfo=jst)
print(scheduled_at.isoformat())
print(scheduled_at.astimezone(ZoneInfo("UTC")).isoformat())
出力例です。
2026-07-07T09:00:00+09:00
2026-07-07T00:00:00+00:00
このように、保存前にUTCへ変換したり、表示時にAsia/Tokyoへ戻したりできます。
よくある失敗と改善例
日付の不具合は、コードが長いから起きるというより、最初の前提が曖昧なときに起きます。
失敗1：日付だけなのにDateやdatetimeへ変換する
NG例です。
const birthday = new Date("1990-04-01");
誕生日のように時刻が不要な値を「瞬間」として扱うと、タイムゾーン変換で表示日がずれる可能性があります。
改善例です。
const birthday = "1990-04-01";
日付だけの項目なら、保存形式をYYYY-MM-DDに固定し、表示時に必要な形へ整えるほうが扱いやすいです。
失敗2：時刻はあるのにタイムゾーンがない
NG例です。
{
"send_at": "2026-07-07 09:00:00"
}
この値だけでは、どの地域の9時かが分かりません。
改善例です。
{
"send_at": "2026-07-07T09:00:00+09:00"
}
または、保存時にUTCへそろえます。
{
"send_at": "2026-07-07T00:00:00Z"
}
どちらを使うかはAPI仕様に合わせます。大事なのは、受け渡しの境界で曖昧な日時を作らないことです。
失敗3：WordPressとサーバーの時刻設定を混同する
WordPressの投稿日時がずれるとき、サーバー時刻だけを直しても解決しないことがあります。
確認する順番は次の通りです。
- WordPress管理画面のタイムゾーン設定
- 使用中テーマやプラグインが日時を独自処理していないか
- 外部APIから受け取る日時がUTCかローカル時刻か
- PHPやサーバー側で日時を変換していないか
特に予約投稿や自動投稿では、WordPress側の表示、外部スクリプト側の生成時刻、APIで送る値が別々に存在します。どこでUTCへ変換し、どこで日本時間へ戻すかを決めておく必要があります。
実務での使い分けチェックリスト
迷ったときは、先に用途を決めると形式を選びやすくなります。
- 日付だけでよい:
YYYY-MM-DD - 実行時刻が必要: タイムゾーンつき日時
- ログやAPI保存: UTCにそろえる設計を検討
- WordPress表示: サイトのタイムゾーン設定を確認
- CSVやExcel連携: 勝手な日付変換を避けるため、入力形式を固定
- ユーザー表示: 保存形式ではなく、読みやすい表示形式へ変換
見落とされがちなのは、日付形式そのものより「その値が日付なのか日時なのか」を決める工程です。ここが曖昧だと、正しいライブラリを使っていてもずれます。
代替手段と関連ツール
日付処理は標準機能だけでも扱えますが、複雑な要件では専用ライブラリやサービス側の仕様確認が必要です。
標準機能で足りる場面
次のような処理なら、標準機能で十分なことが多いです。
YYYY-MM-DD形式の日付を保存する- UTC日時を日本時間で表示する
- WordPressの投稿日時を確認する
- Pythonスクリプトで日次処理を動かす
標準機能を使う利点は、依存関係が増えないことです。小さな自動化や管理画面の入力値処理なら、まず標準機能で考えるのが現実的です。
ライブラリを検討する場面
次のような要件では、日付処理ライブラリやフレームワークの機能を検討します。
- 複数国のユーザーが同じ予定を扱う
- 夏時間のある地域を扱う
- カレンダーUIと連動する
- 営業日、祝日、月末処理が関わる
- API間で日時仕様が異なる
この場合でも、最初に決めることは同じです。保存する値が「日付」なのか「タイムゾーンつき日時」なのかを決め、そのうえでツールを選びます。
まとめ：日付ずれを防ぐために最初に決めること
日付データの扱いで最初に決めるべきことは、フォーマット名ではありません。その値が日付だけなのか、時刻つきの日時なのかです。
実務では、次の分岐を先に置くと判断しやすくなります。
- 人が選ぶ締切日、対象日、誕生日:
YYYY-MM-DD - 予約投稿、通知、期限切れ:
YYYY-MM-DDTHH:mm:ss+09:00などのタイムゾーンつき日時 - サーバー保存、ログ、API連携: UTC基準を検討
- WordPressの表示や予約: サイトのタイムゾーン設定を確認
次に見るべきポイントは、処理の境界です。フォームから受け取るとき、DBへ保存するとき、APIへ送るとき、画面に表示するとき。そのどこかで「日付だけ」を「日時」に変換していないか、またはタイムゾーンなしの日時を作っていないかを確認すると、原因を絞り込みやすくなります。