- Error number
- 1292
- SQLSTATE
22007- Symbol
ER_TRUNCATED_WRONG_VALUE- Product
- MySQL Server
- Versions
- MySQL 5.7, 8.0 and 8.4 (an error in strict mode for INSERT, UPDATE and DELETE)
- Category
- Data Values & Strict Mode
- Last reviewed
- 24 October 2026
On this page
What it means
Error 1292 means MySQL could not convert a value to the type it needed, most often a date string that is not a real date or not in YYYY-MM-DD form, and strict mode turned that into an error.
DATE, DATETIME and TIMESTAMP columns accept only real dates in a format MySQL understands, such as '2026-10-24' or '2026-10-24 14:30:00'. A day that does not exist (30 February), a month 13, a UK or US format such as '24/10/2026', an empty string, a zero date (blocked by NO_ZERO_DATE and NO_ZERO_IN_DATE in the default sql_mode) or a TIMESTAMP outside its range of 1970-01-01 to 2038-01-19 UTC is rejected with 1292, naming the value, the column and the row. A time zone offset such as +01:00 is accepted from MySQL 8.0.19, but on 8.0.46 a trailing Z was rejected.
The second wording, Truncated incorrect DOUBLE value, comes from comparing a string column with a number, as in WHERE ref = 100. MySQL then converts every string to a number; a value such as 'A100' cannot be converted cleanly. In a SELECT that is only a warning, but in strict mode an UPDATE or DELETE fails. Without strict mode, a bad date is stored as 0000-00-00 with warning 1265, which is why old tables often hold zero dates. Comparing a DATE column with an invalid date literal in a WHERE clause gives error 1525 instead; badly formed numbers stored in numeric columns give 1366.
Common causes
- A date in a local format ('24/10/2026' or '10/24/2026') is sent instead of '2026-10-24'.
- A date that does not exist, such as '2026-02-30' or '2026-10-00', or an empty string for a missing date instead of NULL.
- An ISO 8601 timestamp from JavaScript or an API, such as '2026-10-24T14:30:00Z', is written to a DATETIME column.
- A TIMESTAMP column receives a date after 2038-01-19 or before 1970, for example an expiry date or a date of birth.
- A VARCHAR column is compared with a number in an UPDATE or DELETE (
WHERE ref = 100) and some values are not numeric. - A table created under an older, non-strict server still holds zero dates, and an ALTER TABLE that copies the table now rejects them.
Diagnose it
Read-only These statements only read metadata (information_schema, performance_schema and SHOW statements) or your own data. They do not change data, privileges or configuration, so they are safe to run first.
Find staging values that are not valid dates
STR_TO_DATE returns NULL for a string that does not match the format or is not a real date. Use the format your file actually uses.
SELECT id, raw_date
FROM staging_orders
WHERE raw_date IS NOT NULL
AND STR_TO_DATE(raw_date, '%Y-%m-%d') IS NULL; Every row whose date would be rejected (it also returns warning 1411 for each one, which is harmless). Here '24/10/2026' is in the wrong format and '2026-02-30' does not exist.
Find non-numeric values in a string column you compare with numbers
SELECT id, ref
FROM orders
WHERE ref NOT REGEXP '^-?[0-9]+$'; The values behind "Truncated incorrect DOUBLE value". If any come back, compare the column with a quoted string (ref = '100') instead of a number.
Check the column types involved
SELECT column_name, data_type, column_type
FROM information_schema.columns
WHERE table_schema = DATABASE()
AND table_name = 'orders'; Whether the column is DATE, DATETIME or TIMESTAMP (with its 2038 limit), or a VARCHAR being compared with numbers.
Find old zero dates before altering a table
Comparing with the literal '0000-00-00' is itself rejected in strict mode, so test the parts of the date instead.
SELECT id, d
FROM old_orders
WHERE YEAR(d) = 0 OR MONTH(d) = 0 OR DAY(d) = 0; Rows holding zero dates or dates with a zero month or day. Replace them (usually with NULL) before an ALTER TABLE that copies the table.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Convert local date formats with STR_TO_DATE
Changes dataTell MySQL which format the text uses. Invalid dates still fail (with error 1411), so bad rows are not stored silently.
INSERT INTO orders (id, order_date)
VALUES (2, STR_TO_DATE('24/10/2026', '%d/%m/%Y'));
Send dates in MySQL format from the application
Client or network sideFormat dates as YYYY-MM-DD or YYYY-MM-DD HH:MM:SS before binding them, convert ISO strings ending in Z to UTC without the suffix (or to an offset such as +00:00), and send NULL, not an empty string, for a missing date. Use DATETIME rather than TIMESTAMP for dates that can be after 2038 or before 1970.
Compare strings with strings
Changes dataQuote the value when the column is VARCHAR, so no conversion to a number happens. This also lets MySQL use an index on the column, which a string-to-number comparison cannot.
UPDATE orders SET status = 'shipped' WHERE ref = '100';
Replace legacy zero dates with NULL
Changes schemaMake the column nullable, then set the zero dates to NULL, which is what "no date" should be. After that, ALTER TABLE and strict inserts work normally.
Caution: Check with the application owner that nothing relies on '0000-00-00' to mean something special. On a large table, run the ALTER in a maintenance window and take a backup first.
ALTER TABLE old_orders MODIFY d DATETIME NULL;
UPDATE old_orders SET d = NULL WHERE YEAR(d) = 0 OR MONTH(d) = 0 OR DAY(d) = 0;
Examples
A date that does not exist
CREATE TABLE orders (
id INT PRIMARY KEY,
order_date DATE
);
INSERT INTO orders (id, order_date) VALUES (1, '2026-02-30'); -- there is no 30 February
ERROR 1292 (22007): Incorrect date value: '2026-02-30' for column 'order_date' at row 1
Reproduced on MySQL 8.0.46, 24 October 2026.
A UK-format date string
CREATE TABLE orders (
id INT PRIMARY KEY,
order_date DATE
);
INSERT INTO orders (id, order_date) VALUES (2, '24/10/2026');
ERROR 1292 (22007): Incorrect date value: '24/10/2026' for column 'order_date' at row 1
Reproduced on MySQL 8.0.46, 24 October 2026.
An ISO 8601 timestamp ending in Z
CREATE TABLE orders (
id INT PRIMARY KEY,
shipped_at DATETIME
);
INSERT INTO orders (id, shipped_at) VALUES (3, '2026-10-24T14:30:00Z');
ERROR 1292 (22007): Incorrect datetime value: '2026-10-24T14:30:00Z' for column 'shipped_at' at row 1
Reproduced on MySQL 8.0.46, 24 October 2026.
An UPDATE that compares a VARCHAR column with a number
CREATE TABLE orders (
id INT PRIMARY KEY,
ref VARCHAR(20),
status VARCHAR(20)
);
INSERT INTO orders (id, ref) VALUES (1, '100'), (2, 'A100');
UPDATE orders SET status = 'shipped' WHERE ref = 100; -- 100 is a number, ref is text
ERROR 1292 (22007): Truncated incorrect DOUBLE value: 'A100'
Reproduced on MySQL 8.0.46, 24 October 2026.
How to prevent it
Convert dates to YYYY-MM-DD HH:MM:SS in the application or with STR_TO_DATE during imports, send NULL for missing dates, and check staging data before loading it. Choose DATETIME for dates outside 1970 to 2038; TIMESTAMP is for event times near the present.
Compare columns with values of the same type: quote values for VARCHAR columns and do not store numbers as text if you filter on them numerically. Keep strict mode on; without it, bad dates are stored as 0000-00-00 and only a warning tells you.
Common questions
How do I fix "Incorrect datetime value" in MySQL?
Send the date as YYYY-MM-DD HH:MM:SS (or YYYY-MM-DD for a DATE column), make sure it is a real date, and send NULL rather than an empty string when there is no date. For other formats, convert with STR_TO_DATE, and for dates after 2038 use DATETIME instead of TIMESTAMP.
What does "Truncated incorrect DOUBLE value" mean?
A string was compared with, or converted to, a number and part of it was not numeric, for example WHERE ref = 100 on a VARCHAR column containing 'A100'. Quote the value (ref = '100') so MySQL compares strings. In a SELECT it is only a warning; in an UPDATE or DELETE under strict mode it stops the statement.
Why are ISO dates such as 2026-10-24T14:30:00Z rejected?
On the MySQL 8.0.46 server used for this page, the T separator and fractional seconds were accepted but the trailing Z was not. Convert to UTC and drop the Z, or send an explicit offset such as +00:00, which MySQL 8.0.19 and later accept for DATETIME and TIMESTAMP values.
Can I allow 0000-00-00 dates again?
You could remove NO_ZERO_DATE from sql_mode, but that keeps a fake date that every query must special-case. Store NULL for "no date" instead and convert existing zero dates to NULL.
Learn more on CodeWithSQL
Official documentation
- MySQL 8.0 server error message reference
- The DATE, DATETIME and TIMESTAMP types
- Date and time literals
- Type conversion in expression evaluation
Last technically reviewed 24 October 2026; examples and diagnostics run on MySQL 8.0.46. Message templates checked against the server's error catalogue (perror) for that version.