Problem/Motivation
All core schema columns using integers for storing UNIX timestamp use 32bit for the value and so are affected by the Year 2038 bug.
Proposed resolution
Move schema columns using type = 'int' as Unix timestamp storage to size = "big" in order to use 64bit and so support dates until 15:30:08 UTC on Sunday, 4 December 292,277,026,596.
Remaining tasks
- Create/Work on each issue listed below
- Validate if we can still support PHP 32bit, or if we need to drop it. We are currently only warning users.
- Set this issue as fixed when all the children are too.
Below the list of files (schema definitions, fields types, etc.) required to be changed. See comment #24 for full details.
- core/lib/Drupal/Core/Batch/BatchStorage.php
- core/lib/Drupal/Core/Cache/DatabaseBackend.php
- core/lib/Drupal/Core/Field/Plugin/Field/FieldType/TimestampItem.php - #2885413: Timestamp field items are affected by 2038 bug
- core/lib/Drupal/Core/Flood/DatabaseBackend.php
- core/lib/Drupal/Core/Flood/DatabaseBackend.php
- core/lib/Drupal/Core/Queue/DatabaseQueue.php
- core/lib/Drupal/Core/Queue/DatabaseQueue.php
- core/modules/comment/comment.install
- core/modules/dblog/dblog.install
- core/modules/forum/forum.install
- core/modules/forum/forum.install
- core/modules/history/history.install
- core/modules/locale/locale.install
- core/modules/migrate/src/Plugin/migrate/id_map/Sql.php
- core/modules/migrate/tests/src/Unit/MigrateSqlIdMapEnsureTablesTest.php
- core/modules/statistics/statistics.install
- core/modules/system/system.install
- core/modules/system/system.install
- core/modules/taxonomy/src/TermStorageSchema.php
- core/modules/tracker/tracker.install
- core/modules/tracker/tracker.install
- core/modules/views/src/Tests/ViewTestData.php
- core/modules/views/tests/src/Kernel/Handler/FieldDateTest.php
- core/modules/migrate/tests/src/Kernel/HighWaterTest.php
User interface changes
No.
API changes
No.
Data model changes
Size changes from normal to big on some affected schema columns.
Release notes snippet
TBC.
---- original issue ---
I tried entering the date "2100-08-02 17:35 -0500" into the authored on field, and Drupal said it was invalid. Obviously it's a valid date. It's only a hundred years into the future. So if Drupal wants to last for the next century, I suggest this gets fixed.
https://dev.mysql.com/doc/refman/5.7/en/integer-types.html
BIGINT 8
https://www.postgresql.org/docs/10/datatype-numeric.html#DATATYPE-INT
bigint 8 bytes large-range integer -9223372036854775808 to +9223372036854775807
https://www.sqlite.org/datatype3.html
INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value.