Support a per-instance "all-day" option for datetime and datetime range fields

Improved patch which covers:
- adds all_day column in DB for datetime range fields. Set it as disabled for all existing data with datetime type
- allow to enable all day dates for datetime type & set default value for it in field settings
- widget to set all day, making sure that date is stored in UTC when all day is selected (in general timezone is ignored when all day event is set)
- GraphQL - share allDay property for datetime range fields
- formatter - for now only supported inn default formatter. You can specify date format for all day and non all day dates
- js - when you'll select all day, time is set to 00:00:00 for start & end dates

#50 is #49 extended with End date optional #153 ( https://www.drupal.org/project/drupal/issues/2794481#comment-14839868 ✨ Allow end date to be optional Needs review )

@gugalamaciek, could you please share the diff. I have created an MR for 11.x 2ith #49.

Ups... I forgot about schema updates. So this is #49 + schema fixes.

@sakthi_dev I'll try to produce 11.x version in free minute... but can't promise when exactly.

Updated patch in #54 to be compatible with Drupal 10.4.6.
I might take a stab at D11 soon.

I came across this issue when analyzing a problem with a site heavily using date range fields and showing different kind of problems with views showing wrong results. By reading through the comments here I finally figured out what causes those problems.

in #2734255-7: Support a per-instance "all-day" option for datetime and datetime range fields → ::

If you select "All day", then a full date and time is stored in the database, but the start date is set to midnight (the 1st second of the day), and the end date is set to 1 second before midnight on the end date.

#2734255-27: Support a per-instance "all-day" option for datetime and datetime range fields → :

Right now we have

• datetime - date+time
• datetime - date-only (no time is stored, and the presentation is time zone agnostic enforced by the field, eg Dec 25 is a holiday wherever it is observed)
• daterange - date+time
• daterange - date-only (no time is stored, and the presentation is time zone agnostic enforced by the field, eg I can block out the week I am on summer vacation on my calendar)
• daterange- all-day (time is not collected, but is stored midnight to midnight from the author's time zone in the widget and presented in the viewer's time zone, I forget the concrete example I had for this)

The problem

As Drupal datetime works with local time but stores them in the database as UTC, in my case for Central European Time (CET) this can lead to a date range July 14 - July 20 2025 being stored as 2025-07-13T22:00:00 - 2023-05-20T21:59:59. When you want to create a view filtering for start_date <= today <= end_date this can lead to queries like

WHERE
DATE_FORMAT(node__field_promotion_time.field_date_range_value, '%Y-%m-%d') <= DATE_FORMAT('2025-07-15', '%Y-%m-%d')
AND
DATE_FORMAT(node__field_promotion_time.field_date_range_end_value, '%Y-%m-%d') >= DATE_FORMAT('2025-07-15', '%Y-%m-%d')

with actual values from database

WHERE
DATE_FORMAT('2025-07-13T22:00:00', '%Y-%m-%d') <= DATE_FORMAT('2025-07-15', '%Y-%m-%d')
AND
DATE_FORMAT('2023-05-20T21:59:59', '%Y-%m-%d') >= DATE_FORMAT('2025-07-15', '%Y-%m-%d')

actually being

WHERE
'2025-07-13' <= '2025-07-15'
AND
'2023-05-20' >= '2025-07-15'

starts showing the promotion already on July 13 instead of July 14.

As MySQL only knows the date value and not the timezone to interpret it for and Views queries work on SQL level those kind of views will not work.

My solution probably will be to change the field configuration from datetime_type = 'allday' to datetime_type = 'date' and write some heavy update logic to change all existing data accordingly.

But I see at least two issues I have to create:

1. Update documentation about the different datetime_type options on drupal.org as well as in the module's field storage UI to inform site builders and administrators what the different options mean. Because as my colleague who implemented those content types had wrong assumptions what allday for Drupal's fields means, others may have the same wrong assumptions as well (including myself until reading through this issue).
2. Drupal\datetime_range\Plugin\Field\FieldType\DateRangeItem uses Drupal\datetime\DateTimeComputed which doesn't know about datetime_type = 'allday' and therefore treats it as datetime_type = 'datetime' which can lead to unexpected results.

BTW, Drupal\datetime\DateTimeComputed states in it's parsing logic:

// If the format did not include an explicit time portion, then the
// time will be set from the current time instead. For consistency, we
// set the time to 12:00:00 UTC for date-only fields. This is used so
// that the local date portion is the same, across nearly all time
// zones.
// @see \Drupal\Component\Datetime\DateTimePlus::setDefaultDateTime()
// @see http://php.net/manual/datetime.createfromformat.php

which points out that T00:00:00 and T23:59:59 might not be the best options for allday values in respect to local timezone vs. UTC handling.