InletWhat it means
MySQL stores DATETIME as YYYY-MM-DD HH:MM:SS and reads strings in that order (with some
freedom in the separators). Error 1292 means the string couldn’t be read as a valid date and time
for the column, and strict mode (the default) refuses it rather than store a zero date. Nothing is
stored. The message quotes the value, which is usually all you need.
The same number has a second form, for a string that isn’t a number where one was needed:
Truncated incorrect DOUBLE value: 'abc'. That one is covered below.
Common causes
- An empty string for a missing date, from a form or a CSV, instead of
NULL. - The zero date
0000-00-00, which MySQL 8’s default SQL mode doesn’t allow (MariaDB’s does). - A day that doesn’t exist, such as
2026-02-30. - Another format:
10/11/2026 09:30,11-10-2026, or ISO 8601 as JavaScript and many APIs write it,2026-10-11T09:30:00Zor…09:30:00.000Z. MySQL accepts theT, but not theZ. - A
TIMESTAMPoutside its range:TIMESTAMPholds 1970-01-01 00:00:01 to 2038-01-19 03:14:07 UTC; anything earlier or later fails.DATETIMEgoes from year 1000 to 9999.
How to fix it
Send the format MySQL reads
'2026-10-11 09:30:00' always works; so does '2026-10-11T09:30:00'. Most drivers convert their
own date types for you when you pass parameters instead of building strings, which is the best fix.
Send NULL for “no date”
Make the column nullable if it isn’t, and turn empty strings into NULL:
INSERT INTO events (starts_at) VALUES (NULLIF(?, ''));
Convert other formats with STR_TO_DATE()
Say how the string is laid out:
INSERT INTO events (starts_at) VALUES (STR_TO_DATE('10/11/2026 09:30', '%d/%m/%Y %H:%i'));
That stored 2026-11-10 09:30:00: 10 November, because the format said day first. Check which
order your source uses; 10/11 is October in the US.
ISO 8601 with a time zone
MySQL 8.0.19 and later accept an offset such as +02:00 and convert the value to the session’s
time zone; they don’t accept Z. Convert UTC values in your code to 2026-10-11 09:30:00 (or
replace Z with +00:00), and keep the session’s time zone in mind. MariaDB 11.4 accepts neither,
so strip the zone after converting to UTC.
Values outside TIMESTAMP’s range
Birth dates, far-future expiry dates and “never” sentinels such as 9999-12-31 need DATETIME:
ALTER TABLE events MODIFY ts datetime NULL;
Zero dates already in a table
Under strict mode you can’t write '0000-00-00' even in a WHERE clause; compare with the
earliest real date instead:
UPDATE posts SET created_at = NULL WHERE created_at < '1000-01-01';
In a SELECT, MySQL reports such a literal as a different error,
ERROR 1525 (HY000): Incorrect DATETIME value: '0000-00-00 00:00:00'.
Truncated incorrect DOUBLE value
When a string column is compared with a number, MySQL converts each string to a number. In a
SELECT a string such as 'abc' only gives a warning; in an UPDATE or DELETE, strict mode
turns it into this error:
UPDATE events SET day = '2026-10-11' WHERE code = 12;
ERROR 1292 (22007): Truncated incorrect DOUBLE value: 'abc'
code is a varchar and one row holds 'abc'. Compare with a string, WHERE code = '12', which
is also the comparison an index on code can use.
Reproduce it
On MySQL 8.4.11, with events (starts_at datetime, day date, code varchar(10), ts timestamp NULL):
INSERT INTO events (starts_at) VALUES ('');
INSERT INTO events (starts_at) VALUES ('0000-00-00 00:00:00');
INSERT INTO events (starts_at) VALUES ('2026-02-30 10:00:00');
INSERT INTO events (starts_at) VALUES ('10/11/2026 09:30');
INSERT INTO events (starts_at) VALUES ('2026-10-11T09:30:00Z');
INSERT INTO events (ts) VALUES ('2038-01-20 00:00:00');
ERROR 1292 (22007): Incorrect datetime value: '' for column 'starts_at' at row 1
ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'starts_at' at row 1
ERROR 1292 (22007): Incorrect datetime value: '2026-02-30 10:00:00' for column 'starts_at' at row 1
ERROR 1292 (22007): Incorrect datetime value: '10/11/2026 09:30' for column 'starts_at' at row 1
ERROR 1292 (22007): Incorrect datetime value: '2026-10-11T09:30:00Z' for column 'starts_at' at row 1
ERROR 1292 (22007): Incorrect datetime value: '2038-01-20 00:00:00' for column 'ts' at row 1
'…T09:30:00.000Z' and '1969-12-31 00:00:00' in the TIMESTAMP failed the same way. These were
stored: '2026-10-11T09:30:00', '2026-10-11T09:30:00+02:00' (as 07:30:00, the session being in
UTC), the STR_TO_DATE() above, and '2026-10-11 09:30:00' into the DATE column, which kept the
date with Note 1292.
MariaDB 11.4.13 refused the same values except the zero date, which it stored, and also refused the
+02:00 offset. It names the column with its database and table:
ERROR 1292 (22007): Incorrect datetime value: '' for column `seo_err_mysql`.`events`.`starts_at` at row 1
For the string-to-number case it said Truncated incorrect DECIMAL value rather than DOUBLE, and
it only warned about a bad date literal in a SELECT instead of failing with 1525.
In Inlet
Inlet’s filters run on the server, so a date typed into a filter follows the same rules as above. When an insert or update fails, Inlet shows the error and links to this page.