Skip to content

fix: use DATETIME instead of TIMESTAMP for MySQL/TiDB tstamp column (Y2K38)#1053

Open
Yanhu007 wants to merge 1 commit intopressly:mainfrom
Yanhu007:fix/mysql-y2k38-datetime
Open

fix: use DATETIME instead of TIMESTAMP for MySQL/TiDB tstamp column (Y2K38)#1053
Yanhu007 wants to merge 1 commit intopressly:mainfrom
Yanhu007:fix/mysql-y2k38-datetime

Conversation

@Yanhu007
Copy link
Copy Markdown

Fixes #432

Problem

The goose_db_version table uses MySQL TIMESTAMP type for the tstamp column. TIMESTAMP stores values as a 32-bit signed Unix timestamp, with a maximum of 2038-01-19 03:14:07 UTC (the Year 2038 problem).

Fix

Change to DATETIME for both MySQL and TiDB dialects:

  • DATETIME supports dates up to 9999-12-31 23:59:59
  • Use CURRENT_TIMESTAMP (SQL standard) instead of now() for the default

Only affects newly created tables. Existing tables continue to work.

MySQL TIMESTAMP type is affected by the Year 2038 problem — it
stores values as a 32-bit signed integer Unix timestamp, limiting
the maximum representable time to 2038-01-19 03:14:07 UTC.

Change the tstamp column type to DATETIME for both MySQL and TiDB
dialects. DATETIME stores the date and time as-is with a range up
to 9999-12-31 23:59:59, avoiding the Y2K38 overflow.

Also use CURRENT_TIMESTAMP (SQL standard) instead of now() for the
default value for consistency.

Note: this only affects newly created goose_db_version tables.
Existing tables retain their TIMESTAMP column.

Fixes pressly#432
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Type of the 'tstamp' field in the 'goose_db_version' table (Y2K38)

1 participant