The maximum allowed timestamp is limited on 32-bit systems (includes the 32-bit Acquia Dev Desktop v2 app, running on 64-bit machines) - e.g. it can't handle dates beyond 19 January 2038 (the 2038 bug) or of December 13 1901 and earlier.
There are multiple uses of getTimestamp() and strtotime() in core alone, directly and via Drupal's DateTimePlus class which PHP DateTime.
These return FALSE for dates out of range on systems affected by the 2038 bug (see #9 → for a simple test), which means the date is invariably incorrectly shown as 1970-01-01.
e.g. strtotime():
strtotime('Jan 19 2038');
2147472000
strtotime('Jan 20 2038');
false
Field types/widgets affected: (at least) the Date only and Date and Time, including "Select list" widget. You can choose years outside the 1900 to 2038 range, but because PHP can't handle them they will be stored/displayed as 1970-01-01 without warning.
Warn 32-bit users, on installation and on /admin/reports/status, plus additional test coverage #13 →
Warnings on install, on system status (translatable text string)
None.
None.
Fixed
8.4 ⚰️
There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Regarding #121 - this would be an easy fix. Most schema uses 'timestamp' storage item so all what we need is update
/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/TimestampItem.php class
and add implementation of defaultStorageSettings() that returns ['size'=>'big']