web-dev-qa-db-ja.com

誤った日時値データベースエラー番号：1292

不正な日時値0000-00-00 00:00:00 +0000データベースエラー番号：1292

こんにちは皆さん、ホスティング会社によるサーバーのアップグレードに問題があります。問題を解決できるように、何が起きているのかを理解しようとしています。

私のサーバーは最近サーバーバージョン5.6.17にアップグレードされましたが、日時の値が間違っているというエラーが各地で表示されていますか？

Datetimeの最後に+0000を追加するようですが、なぜかわかりません。これは5.5では完全に正常に動作していましたが、最近のアップグレードはタイムスタンプの動作に影響を与えました

Error Number: 1292

Incorrect datetime value: '2014-04-02 08:49:43 +0000' for column 'created' at row 1

INSERT INTO `activitylog` (`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) VALUES ('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43 +0000')

このsqlクエリを+0000なしで変更すると機能しますか？

これは、テーブル上のDATETIMEのタイプであるすべてのものに影響します。

他の誰かが同様の問題を抱えていましたが、今はこれを機能させるための解決策は何ですか？現時点では、クエリ文字列でNOW（）を呼び出すのではなく、すべてのPHP関数を日付/時刻をエコーするように変更する必要があります

phpmysqldatabasedatetime
18
Luke O'Regan

MySQL 5.7にアップグレードした後、クエリで日付を指定していなくても、このエラーがランダムな状況で発生し始めたことを発見しました。

これは、previousバージョンのMySQLが0000-00-00 00:00:00（デフォルト）のような日付をサポートしたためですが、5.7.4はNO_ZERO_DATE設定。新しいMySQLバージョンを使用しているときに古いデータが残っている場合、ランダムエラーが発生する可能性があります。

すべてのゼロの日付を別の日付にリセットするには、このようなクエリを実行する必要がありました。

# If the columns supports NULL, use that
UPDATE table SET date_column = NULL WHERE date_column < '1000-01-01';

# Otherwise supply another default date
UPDATE table SET date_column = '1970-01-01' WHERE date_column < '1000-01-01';

または、NO_ZERO_DATE設定を調整することもできますが、ドキュメントについての説明に注意してください：

NO_ZERO_DATEモードは、サーバーが有効な日付として「0000-00-00」を許可するかどうかに影響します。その効果は、厳密なSQLモードが有効になっているかどうかにも依存します。

  • このモードが有効になっていない場合、「0000-00-00」が許可され、挿入しても警告は生成されません。

  • このモードが有効な場合、「0000-00-00」が許可され、挿入すると警告が生成されます。

  • このモードとストリクトモードが有効な場合、 '0000-00-00'は許可されず、IGNOREも指定されない限り、挿入はエラーを生成します。 INSERT IGNOREおよびUPDATE IGNOREの場合、 '0000-00-00'が許可され、挿入すると警告が生成されます。

MySQL 5.7.4以降、NO_ZERO_DATEは非推奨になりました。 MySQL 5.7.4から5.7.7では、NO_ZERO_DATEは明示的に名前が付けられても何もしません。代わりに、その効果は厳密なSQLモードの効果に含まれています。 MySQL 5.7.8以降では、NO_ZERO_DATEは明示的に指定されたときに効果があり、MySQL 5.7.4の前のように厳密モードの一部ではありません。ただし、strictモードと組み合わせて使用​​する必要があり、デフォルトで有効になっています。厳密モードを有効にせずにNO_ZERO_DATEを有効にすると、警告が発生します。詳細については、MySQL 5.7のSQLモードの変更を参照してください。

NO_ZERO_DATEは非推奨であるため、今後のMySQLリリースでは個別のモード名として削除され、その効果は厳密なSQLモードの効果に含まれます。

From http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date

17
Simon East

わかりましたので、この同じエラーが発生していました。私がそれを修正するためにしたことは、これらのコード行を使用して、私が問題を抱えていたデータベースを照会することでした：

SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session;
SET sql_mode = '';
SET GLOBAL sql_mode = '';

コードの最初の行（SELECT）は、「SESSION」と「GLOBAL」の両方の現在の設定を確認することです。両方を空の文字列に設定し、選択を再度実行すると、何も返されません（空になります）。

SET SESSION sql_mode = '';も使用する必要があるかもしれませんが、これで問題は解決しました。基本的に、そこにある設定の1つは、日付がデータベースに入る方法をジャッキアップすることでした（「YYYY-MM-DD HH：MM：SS AM/PM」形式で取得していました）。 NO_ZERO_IN_DATEと他の日付オプションを削除しても助けにはなりませんでした。

私のサイトは今のように機能しています。これがお役に立てば幸いです。

8
JedtheMarine

短い答え-クエリのNOW()は、MySQL DATETIMEカラムで完全に機能するはずです。

より長い答え-あなたが今までどのように見たのかわかりません+0000動作しています。 DATETIME列の形式は'YYYY-MM-DD HH:MM:SS'。タイムゾーンの違いに関しては、通常、プログラムで処理する必要があります。 MySQLはTIMESTAMPデータを保存および取得するときにローカル時間をUTCに変換し、元に戻しますが、DATETIMEまたは他の日付/時刻列ではこれを行いません。

6
Ragdata

誤った日時値データベースエラー番号：1292

TIMESTAMPデータ型は、日付と時刻の両方の部分を含む値に使用されます。 TIMESTAMPの範囲は'1970-01-01 00:00:01' UTC〜'2038-01-19 03:14:07' UTCです。

DATETIMEタイプは、日付と時刻の両方の部分を含む値に使用されます。 MySQLは、'YYYY-MM-DD HH:MM:SS'形式でDATETIME値を取得して表示します。サポートされる範囲は'1000-01-01 00:00:00' to '9999-12-31 23:59:59'です。

このタイプはDateTime形式で使用する必要があります

INSERT INTO `activitylog` 
(`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) 
VALUES 
('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43')

https://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html

https://dev.mysql.com/doc/refman/5.0/en/datetime.html

http://bugs.mysql.com/bug.php?id=70188

更新：1

コード'2014-04-02 08:49:43 +0000'のようなspaceを削除し、'2014-04-02 08:49:43+0000'のようなコードを変更する必要があります。完全なクエリは次のとおりです。

INSERT INTO `activitylog` 
(`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) 
VALUES ('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43+0000')

こちらをご覧ください： http://sqlfiddle.com/#!2/a2581/23099

4
jmail

元のmy.cnfのsql_modelは次のように設定されていました。

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

NO_ZERO_IN_DATEとNO_ZERO_DATEを削除しようとしましたが、効果はありませんでした。しかし、すべての用語を削除した場合（sql_modeが空の場合）、エラーはなくなりました。

元のsql_modeに戻り、1行1列の用語を削除して、どれが原因であるかを確認すると考えました。最初の試みはSTRICT_TRANS_TABLESを削除することでした：

sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

エラーなし。したがって、STRICT_TRANS_TABLESが原因であるように見えます。

1
RDVS