MySQL upgraded legacy TIME, TIMESTAMP, or DATETIME columns to the new binary format and issued error 1880 as a notice.
ER_OLD_TEMPORALS_UPGRADED means MySQL automatically converted old-format TIME, TIMESTAMP, or DATETIME columns to the modern binary format during an upgrade. No action is usually needed, but running mysql_upgrade and checking table definitions ensures full compatibility.
ER_OLD_TEMPORALS_UPGRADED
MySQL error 1880 with condition name ER_OLD_TEMPORALS_UPGRADED informs you that TIME, TIMESTAMP, or DATETIME columns created before MySQL 5.6.4 have been transparently converted to the new binary storage format introduced in MySQL 5.6 and required in 5.7 and later.
The message is raised during mysql_upgrade, an in-place server upgrade, or a CHECK TABLE ... FOR UPGRADE command. It is not a fatal error but a notice that metadata has changed, and applications should review column defaults and precision.
The server triggers the notice when it finds tables that still store temporal values in the legacy packed format used prior to 5.6.4. When the upgrade process rewrites the .frm definition to the new format, it emits ER_OLD_TEMPORALS_UPGRADED to document the change.
The message can also appear when an ALTER TABLE, OPTIMIZE TABLE, or table rebuild forces the engine to rewrite rows that contain old-format temporal columns.
No manual fix is usually required because MySQL already upgraded the column definition. However, you should run CHECK TABLE ... FOR UPGRADE on all databases, back up the upgraded tables, and verify that your application handles any new fractional-seconds precision.
If you prefer explicit control, dump the affected table, drop it, and reload it with CREATE TABLE statements that include explicit fractional precision such as DATETIME(6) to avoid implicit conversions in future upgrades.
Upgrading from MySQL 5.5 or 5.6 to 8.0 often shows hundreds of ER_OLD_TEMPORALS_UPGRADED messages. Confirm that mysql_upgrade completed successfully, then restart the server to reload the new metadata cache.
Replication setups: run mysql_upgrade on each replica before pointing it at the 8.0 primary, or stop replication, upgrade, run mysql_upgrade, and then resume to avoid metadata mismatch.
Create new tables with explicit DATETIME, TIMESTAMP, and TIME precision so future upgrades skip implicit rewrites. Always run mysql_upgrade immediately after installing a newer server version.
Include CHECK TABLE ... FOR UPGRADE and ALTER TABLE ... FORCE steps in your CI pipelines. Galaxy users can store these maintenance scripts in a shared Collection so all teammates reuse the same vetted commands.
ER_TABLE_UPGRADE_REQUIRED (error 1719) appears when the server detects tables in an old format that cannot be auto-upgraded and requires manual ALTER TABLE. ER_CANT_OPEN_TABLE (error 1137) may follow if you attempt to access a table before upgrading.
Upgrading a server from version 5.5 or early 5.6 to 5.6.4+ or 5.7 triggers automatic conversion of legacy temporal columns.
Running mysql_upgrade or CHECK TABLE ... FOR UPGRADE manually forces the server to rebuild tables with old temporal formats.
Executing ALTER TABLE, OPTIMIZE TABLE, or a table rebuild on a table that still stores temporal columns in the packed legacy format.
Restoring a dump created on a very old server into a newer server without prior ALTER TABLE rewrites.
Indicates that a table uses an old format that cannot be auto-upgraded and requires manual ALTER TABLE.
Appears when the server fails to open a table, often after a failed upgrade.
Raised when a temporal column has an invalid default value after an upgrade.
No. The message is informational. The upgrade continues after converting the columns.
You can, but you should still back up the upgraded tables and test your application.
Galaxy lets you store and share your upgrade scripts in a Collection, ensuring every teammate runs the same vetted commands.
Run mysql_upgrade on each replica before restarting replication to avoid metadata mismatches.
.avif)
.avif){kind=logo}
