午後 3:40 に入った注文の「作成日時」が午前 9:40 と表示されるようなバグは、システムへの信頼をすぐに損ないます。機能的に何かが壊れるからではなく、すべての画面のすべてのタイムスタンプを、スタッフが頭の中で直さなければならなくなるからです。
実際のずれを突き止める
ずれは常に 6 時間で、これは UTC とバングラデシュ標準時（UTC+6）の差とちょうど同じです。設定画面を開く前から有力な手がかりでした。WordPress サイトのタイムゾーンが Asia/Dhaka ではなく UTC に設定されていたため、プラットフォームが生成・表示するすべてのタイムスタンプは、UTC としては技術的に正しく、現地時間で読む人にとっては間違っていました。
設定は 1 つ、でも先に確認すべき問いがある
修正そのものは、「設定 → 一般」での 1 か所の変更だけでした。より重要だったのは、データの移行も必要かどうか、つまり既存の注文に保存されたタイムスタンプも書き換える必要があるかという問いです。WooCommerce の場合、答えは「いいえ」です。注文のタイムスタンプは内部で UTC として保存され、ページを読み込むたびに表示の時点でサイトに設定されたタイムゾーンへ変換されます。サイトの設定を直したことで、データベースを何も変えずに、既存のすべての注文の表示時刻がさかのぼって即座に正しくなりました。
ポイントのまとめ
- 一定の、ちょうど何時間という単位のタイムスタンプのずれは、コードのバグではなくタイムゾーンの設定ミスであることがほとんどです。まず既知の UTC との時差と比べてみましょう。
- プラットフォームが UTC で保存して表示時に変換するのか、変換済みの現地時間を保存するのかを知っていれば、設定の修正だけで十分かどうかがすぐにわかります。
- いちばん小さな修正こそ書き残す価値がある場合があります。設定 1 行の変更が、ストア全体にさかのぼって本当の効果をもたらしたのです。
関連記事：キャッシュの TTL が原因の断続的な 403 エラー、Web サイト保守で実際に行うこと。
ご自身の WooCommerce や WordPress の管理画面で同じような制約にお困りですか？ご相談ください。ArtinTech Solution はまさにこうしたストア向けのカスタムツールを開発しています。