Problem/Motivation
The timestamp field item storage type is [signed] int, which is currently 4 bytes in most DB systems (MySQL and PostgreSQL, SQLite is not affected).
This results in having values limited to the range -2,147,483,648 to 2,147,483,647, which converted to Unix timestamp set the minimum date value 1901-12-13 and maximum 2038-01-19.
See #2795489: 2038 bug with PHP timestamps on 32-bit systems - warn users? and particularly comment #42 . Note that patch was committed so users have been warned about this for several versions now -- this issue is about actually solving the problem.
Proposed resolution
In order to allow these field type to use dates out of range the best solution is to use 'bigint' as storage type, increasing the value memory space from 4 to 8 bytes. The new range will be 9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 quite enough to remove any concern.
Adds a node and node_revision table for the field created in existing fixture, drupal.timestamp-formatter-settings-2921810.php.
Remaining tasks
Update Timestamp item schemaAdd test coverage#19batch process the hook_update()write upgrade path tests33.1 set minimum value for #date_year_range(see #57)47 are more test cases needed?48.1 $entity->validate() tests</li>48.5, needs review. Is the test for the timestamp type robust?See #63, #66 and #77. We need a way to update schema on those fields with data, but without removing the checks fromSqlContentEntityStorageSchemaprovide an opt out mechanism #3406172: Provide a flag to allow updates to stored schema for fields- Bail after an amount of time with an error telling people to use the opt-out mechanism and options for doing the alters themselves
- Provide an item in the status report to indicating if the timestamp fields have been fixed or not
User interface changes
No UI changes should be required.
API changes
No API changes should be required.
Data model changes
TimestampItem type int size should be big.