【技術メモ】JavaScript の ISO8601 を送信すると PHP・MySQL が 500 を返す理由と,サーバ側 timestamp 生成で解決する仕組み

Web アプリケーションにおいて,クライアント側で生成した ISO8601 形式の timestamp を PHP API に送信したところ,MySQL が 500 エラーを返す事象が発生した。

本記事では,その原因と,サーバ側で timestamp を生成する方式に変更することで問題が解決した理由を技術的に整理する。

1. 発生していた問題の概要

JavaScript 側では,以下のような ISO8601 形式の timestamp を送信していた。

コード

2026-09-24T01:21:12.090Z

PHP 側では DateTime::createFromFormat(DateTime::ATOM) により変換を試みていたが,MySQL の datetime 型との整合性が取れず,INSERT が失敗し,API が 500 を返していた。

2. ISO8601 が MySQL の datetime と整合しない理由

2.1 T と Z を含む形式は MySQL が受け付けない

MySQL の datetime 型は以下の形式のみを受け付ける。

コード

YYYY-MM-DD HH:MM:SS

一方,ISO8601 は以下のように T と Z を含む。

コード

2026-09-24T01:21:12.090Z

この形式は MySQL の datetime と直接整合しない。

2.2 ミリ秒 .090 を含む

ISO8601 はミリ秒を含むが,MySQL の datetime は秒までしか扱わない。

コード

2026-09-24T01:21:12.090Z  ← ミリ秒あり

MySQL 5.6 系や MariaDB の一部環境では,datetime(3) が内部的に無効化されており,ミリ秒付きの値を INSERT するとエラーになる。

2.3 タイムゾーン Z を含む

MySQL の datetime はタイムゾーン情報を保持しないため,Z(UTC)を含む値はそのままでは扱えない。

3. PHP の DateTime::ATOM が不安定である理由

DateTime::createFromFormat(DateTime::ATOM) は ISO8601 をパースするが,ミリ秒付きの形式を完全に扱えない場合がある。

コード

2026-09-24T01:21:12.090Z  ← ミリ秒あり

この場合,DateTime::createFromFormat() が null を返し,結果として PHP 側で timestamp が null になる。

しかし,MySQL のテーブル定義は以下のとおりである。

コード

timestamp datetime NOT NULL

null を INSERT しようとすると,MySQL が拒否し,API が 500 を返す。

4. サーバ側で timestamp を生成すると問題が解決する理由

今回の修正では,以下のように PHP 側で timestamp を生成する方式に変更した。

php

$timestamp = date("Y-m-d H:i:s");

この方式が最も安定する理由は以下のとおりである。

4.1 MySQL の datetime と完全整合する形式になる

PHP の date("Y-m-d H:i:s") は MySQL の datetime と完全一致する。

コード

2026-09-24 01:21:12
  • ミリ秒なし
  • タイムゾーンなし
  • T や Z を含まない
  • MySQL が確実に受け付ける形式

4.2 クライアント依存の時刻ズレを排除できる

クライアント側の時刻は以下の理由で不安定である。

  • PC の時計がずれている
  • スマホの時計がずれている
  • タイムゾーン設定が異なる
  • ブラウザが ISO8601 を返す

サーバ側の date() は常に正確であり,ログの一貫性が保たれる。

4.3 PHP → MySQL の INSERT が確実に成功する

ISO8601 を排除し,MySQL が受け付ける形式を送ることで, $stmt->execute() が常に成功するようになり,500 エラーが消えた。

5. 結論

今回のエラーは,ISO8601(ミリ秒+タイムゾーン付き)と MySQL の datetime の非整合性が原因であった。 PHP 側で timestamp を生成する方式に変更することで,MySQL が確実に受け付ける形式となり,INSERT が安定して成功するようになった。

ログシステムにおいて,timestamp はサーバ側で生成する方式が最も安全であり,今回の事例はその重要性を示すものである。

6. 更新履歴

  • 2026年9月24日 新規作成

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です