Composer friendly patches adding timezones to core date fields

I have tested applying this patch on a site running both D9.4.8 and D9.4.10. The patch applies cleanly once i removed this patch ✨ Add option to show only start or end date in the DateTime Range custom formatter Needs review .

Running "drush updb" seems to mostly do its thing by adding TZ column to tables with date columns except i get this error for 1 instance it is trying to update:

"query": "SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'scheduled_date_value
  ' doesn't exist in table: ALTER TABLE "sitewide_alert_field_data" ADD INDEX `value_timezone` (`scheduled_date_value`,
  `scheduled_date_timezone`); 

this is from the Sitewide Alert module. I suspect this is due to their odd column name for their date property: scheduled_date__value and scheduled_date_end__value. For some reason they have a double underscore. I guess I could raise a bug on that module but not sure Drupal has a requirement for naming of this. More likely this update script should be more encompassing. That being said, the tz field is still added; but only for the start date.

After the patch (and updb) I can now see the UI option for the field settings to "Store a timezone"; but there is no timezone selector added to the widget.

Hmm, interesting.

I have added new date and daterange fields to an existing bundle (node) and in widget settings i now see the "Preferred time zone for each date" option. Which when selected, does give me a TZ selector on my node form.

My report above was based on setting an existing field (which also happened to be on a paragraph). It does have the TZ options (user/site/fixed) for the widget; but does not have the "Preferred time zone for each date" option.

It seems as though this only works for new fields (fields with no content). For existing fields there is this message as might be expected: "There is data for this field in the database. The field settings can no longer be changed." and the checkbox to set to "Store a time zone" is disabled, initially. But once the form finishes loading; the disabled attr is gone and i can set the value (which i had done for my test above); but when i go back to edit storage settings i see the checkbox did not get set (which is why the option is not available for the widget).

I suspect a core bug here as well in that it allows me to save the field storage form and tells me it was successful; even though it was not.

UI bugs aside, is this expected operation here? Should this change in storage be disabled due to existing content? The tz field tables were modified regardless; so not sure i see harm in allowing new entries to set tz. And somewhat related; not sure why the tz property is added to date fields but not populated with the default site TZ. Is there a reason we wouldnt populate these? Of course if these fields dont use time then no reason; but the tz field is added to the table regardless of the time setting (I guess thinking is maybe they have no content yet so they could be modified to include time?).

I think the update as it is now: add tz field in all tables and dont prepopulate existing entries with tz is valid. But i think this should also allow changing existing fields (with content) but on that action go in and populate all the existing content with site's default tz.

As it seemed silly that i wouldnt be able to change the storage setting (through the UI); i simply changed it manually with:

use Drupal\field\Entity\FieldStorageConfig;

$config = FieldStorageConfig::loadByName('paragraph', 'field_session_date');
$config->setSetting('timezone_storage', 1)->save();

this works and now allows me to set the per node option on the widget setting. Which in turn gave me the tz widget added to my date widget. But, when i try to save the node i get this error:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_session_date_range_timezone' in 'field list': INSERT INTO "node__field_session_date_range" ("entity_id", "revision_id", "bundle", "delta", "langcode", "field_session_date_range_value", "field_session_date_range_timezone", "field_session_date_range_end_value") VALUES (:db_insert_placeholder_0, ...

which is odd that it is adding _range everywhere when the field name is only field_session_date. Perhaps this is fixed in the later (D9.5 patches?). Checking now.

Reroll for 10.1.

Reroll off patch #42

#42 applied and seems to be working for me on Drupal 10.1.4 with MySQL 10.4.

#43 threw this error: PHP Fatal error: Trait "Drupal\datetime\Plugin\Field\ConfigurableTimezoneTrait" not found in /app/web/core/modules/datetime/src/Plugin/Field/FieldFormatter/DateTimeFormatterBase.php on line 22

Thanks to all keeping this alive!

based on feedback in #44

Applying patch in #42 gives me the following error

error: patch fragment without header at line 1127: @@ -23,7 +26,11 @@ class DateTimeFieldTest extends DateTestBase {

I suppose I also got the error in #44, because now I see that I was actually using a local file 3185750-44.patch for patching. I suppose I have forgotten to get back to the issue and attach it. I have renamed it to 3185750-47.patch and will upload it here.

I have rerolled patch #47 against 10.2.x
No conflicts were shown when rebasing.

The patch for 10.2 causes this error:

Site/admin/structure/types/manage/event/fields/node.event.field_date_recur|http://activelyout.prime.cciplatform.com/admin/structure/types/manage/ev...|1||TypeError: Unsupported operand types: string * int in Drupal\datetime\Plugin\Field\FieldType\DateTimeItem->storageSettingsForm() (line 116 of drupal10.2/html/core/modules/datetime/src/Plugin/Field/FieldType/DateTimeItem.php).

I can confirm the same issue as reported in comment #49, after applying patch for branch 10.2.
This can be reproduced if you try to use the Date field storage settings form.
There is a additional plus character at line 726 which breaks form element in the storageSettingForm.

Uploading corrected patch 3185750-48 from balagan.

previous patch had index removed, uploading corrected for 10.2.

Re-roll of patch in #51 for 10.3 / 11

Oops; I'd introduced an error on /core/modules/datetime_range/src/DateTimeRangeTrait.php and /core/modules/datetime_range/src/Plugin/Field/FieldFormatter/DateRangeCustomFormatter.php - I think this fixes it.