MySQL 5.6 DateTime Falscher Datums- / Uhrzeitwert: '2013-08-25T17: 00: 00 + 00: 00' mit Fehlercode 1292


15

Ich verwende MySQL 5.6 und habe ein Programm, das die folgende SQL-Anweisung für meine Datenbank ausführt:

UPDATE `m_table` SET `s_time` = '2013-08-25T17:00:00+00:00' WHERE id = '123' 

Leider erhalte ich den folgenden Fehler: Falscher Datums- / Uhrzeitwert: '2013-08-25T17: 00: 00 + 00: 00' für die Spalte 's_time' in Zeile 1

Der Datentyp für s_time ist DateTime.

Ich habe bereits versucht, die Eigenschaft allow_invalid_dates über die Workbench festzulegen.

Kann jemand diesen Fehler verstehen und mir bitte erklären? Ich weiß, dass die Anweisung funktioniert , wenn ich die Anweisung manuell in UPDATE m_tableSET s_time= '2013-08-25 17:00:00' WHERE id = '123' ändere.

Leider kann ich das Programm, das die SQL-Anweisung liefert (die meines Erachtens vom Ersteller des Programms gültig ist), nicht ändern und ich kann auch nicht verstehen, was die +00: 00 symbolisiert.

Vielen Dank

Antworten:


24
'2013-08-25T17:00:00+00:00'

Dies ist ein gültiger iso-8601- Datums- / Uhrzeitwert, aber kein gültiges MySQL-Datums- / Uhrzeitliteral . In diesem Punkt ist der Entwickler falsch.

In der Dokumentation wird erklärt, was zu ALLOW_INVALID_DATEStun ist:

Stellen Sie nur sicher, dass der Monat im Bereich von 1 bis 12 und der Tag im Bereich von 1 bis 31 liegt.

Mit anderen Worten, 2013-02-31wäre ein zulässiges Datum, wenn allow_invalid_datesgesetzt ist. Diese Option führt nichts aus, wenn das Datum oder die Uhrzeit nicht einmal in einem gültigen Format für MySQL vorliegen.

Das +00:00ist die Zeitzone von Offset UTC . In diesem Fall wird die Uhrzeit in UTC angegeben, sodass der Versatz null Stunden und null Minuten beträgt.

Ihre Abhilfe wäre das zu entfernen , STRICT_TRANS_TABLESvon der sql_modedie eine Standard in der Konfigurationsdatei während der MySQL 5.6 Installation erstellt ist ... Sie müssen die Auswirkungen der Veränderung dieses sorgfältig prüfen, aber es erlaubt den Daten in zu gehen.

mysql> select @@sql_mode;
+--------------------------------------------+
| @@sql_mode                                 |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into datetimetest(dt) values ('2013-08-26T12:00:00+00:00');
ERROR 1292 (22007): Incorrect datetime value: '2013-08-26T12:00:00+00:00' for column 'dt' at row 1

-- remove STRICT_TRANS_TABLES -- note that executing this only removes it for your
-- current session -- it does not make a server-wide config change

mysql> set @@sql_mode='no_engine_substitution';
Query OK, 0 rows affected (0.00 sec)

mysql> select @@sql_mode;
+------------------------+
| @@sql_mode             |
+------------------------+
| NO_ENGINE_SUBSTITUTION |
+------------------------+
1 row in set (0.00 sec)

-- now MySQL will accept the invalid value, with a warning

mysql> insert into datetimetest(dt) values ('2013-08-26T12:00:00+00:00');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+-----------------------------------------+
| Level   | Code | Message                                 |
+---------+------+-----------------------------------------+
| Warning | 1265 | Data truncated for column 'dt' at row 1 |
+---------+------+-----------------------------------------+
1 row in set (0.00 sec)

-- the value did get inserted, but the time zone information was lost:

mysql> select * from datetimetest;
+----+---------------------+
| id | dt                  |
+----+---------------------+
|  1 | 2013-08-26 12:00:00 |
+----+---------------------+
1 row in set (0.00 sec)

Vielen Dank. Am Ende habe ich den Programmierer gebeten, den PHP-Code, mit dem die SQL-Anweisung erstellt wurde, so zu ändern, dass er dem MySQL-Standard entspricht. Dies ist jedoch eine interessante Problemumgehung. Das Seltsame ist, dass die ursprüngliche SQL-Anweisung in älteren MySQL-Versionen funktioniert.
Andrew

2
Das Einschließen STRICT_TRANS_TABLESin eine Standardkonfigurationsdatei wurde nur in MySQL 5.6 eingeführt, was die Verhaltensänderung erklärt. Wenn Sie dies SQL_MODEin früheren Versionen aktivieren , würde die Abfrage auch in diesen Versionen unterbrochen.
Michael - sqlbot

Du hast mir gerade das Leben gerettet. Vielen Dank für die Antwort!
Rafaels88
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.