In a recent project, when the App side called the interface to add new data, it was found that the insertion failed. When checking the log, an error was reported.
Cause: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect datetime value: '1970-01-01 08:00:00' for column 'lastModifyTime' at row 1
It turns out that the value inserted in the lastModifyTime field is not supported, but this field generally does not need to be passed in from the front end. You can set the field to default to the current time in MySQL and update it according to the current timestamp. But if you look carefully at the error message, it seems that there is no problem with the format of the time 1970-01-01 08:00:00. Why can't it be inserted? After ruling out other possible causes, I suspected that it might be a problem with this value. Check the official documentation of MySQL and you can see the description of the timestamp type.
The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.
It turns out that the supported range of timestamp is 1970-01-01 00:00:01 to 2038-01-19 03:14:07, so why 1970-01-01 08:00:00 seems to be within this range but is not supported? Well, keep reading
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone system variable. For more information, see Section 10.6, “MySQL Server Time Zone Support”.
UTC is added after the time range supported in the MySQL document, indicating that this time is related to the time zone. MySQL will convert the timestamp type field from the current time zone to the UTC time zone when storing. We can check the current time zone
show variables like "%time_zone%";
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CST |
| time_zone | SYSTEM |
+------------------+--------+
Converting from the current time zone to the UTC time zone requires subtracting 8 hours, so the last time 1970-01-01 08:00:00 is stored in MySQL and actually becomes 1970-01-01 00:00:00, which is not within the range of the timestamp type. Guilty~
Author: There is no nickname available
Link: https://www.jianshu.com/p/efcd369981e0
Source: Jianshu
The copyright of Jianshu belongs to the author. For any form of reprinting, please contact the author for authorization and indicate the source.