If you set a a date value on a date field of an entity using
\Drupal\Core\TypedData\Plugin\DataType\DateTimeIso8601::setDateTime()
and then try to save the entity you will receive a fatal error:
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22001]: String data, right truncated: 1406 Data too long...
That is because DateTimeIso8601::setDateTime() uses PHP's c date format which is of the form 2004-02-12T15:19:21+00:00. DateTimeItem::schema() intends to save dates without the timezone offset suffix, so it enforces a maxlength of 20.
Even if we increase the maxlength and allow saving dates in the c format in the database you cannot actually use them, because DateTimeComputed does not function with dates in that format either.
Long story short: The typed-data-level handling of dates and the field-level handling of dates both work fine on their own, but not when used together. As the latter builds on the former that is a problem as can be seen above.
Change the storage format to explicitly store a time zone offset value of '+00:00' in the field value. This matches the STORAGE_TIMEZONE. Using the long form for the offset, instead of the 'Z' shorthand, is used to future proof the storage length in case the offset gets changed in the future to allow any valid +HH:MM value.
- update path for daterange
- test with base fields
- figure out test coverage for field definitions?
None.
DATETIME_DATETIME_STORAGE_FORMAT and DateTimeItemInterface::DATETIME_STORAGE_FORMAT are different.
Field values are stored with an explicit time zone offset of '+00:00' per the updated storage formats.
Needs work
11.0 🔥
A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.
The patch will have to be re-rolled with new suggestions/changes described in the comments in the issue.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
