datetime_range fields have confusing options for date type setting

This came up as the daily BSI target

Since I don't use the date range field often guess I've never noticed this but indeed it's not clear. Searching the code

// All day fields start at midnight on the starting date, but are
          // stored like datetime fields, so we need to adjust the time.
          // This function is called twice, so to prevent a double conversion
          // we need to explicitly set the timezone.

I would of never known that.

Wonder if a simple solution would be just to add a simple description for the 3 options?

Seems like a good task for a new user.

Thanks but part of the ticket was also updating the issue summary please. With UI changes screenshots should be included too please

If you are another contributor eager to jump in, please allow the previous poster(s) at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

Think this is an improvement for sure

This is changing text on the UI so it should pass the Usability Core Gate. Following that, this should be tagged 'Usability', so adding tag.

While this is an improvement, I think we should get the usability folks to confirm the new text, so tagging for a review. I will comment in the #ux channel about this. There are already screenshots here, so this should be ready for them to review.

And un-assigning per Assigning ownership of a Drupal core issue.

Usability review

We discussed this issue at #3587931: Drupal Usability Meeting 2026-05-08. That issue has a link to a recording of the meeting. I am giving issue credit here to the attendees at the usability meeting: @benjifisher, @pallavi singh3013, and @rkoller.

We agree that the proposed change is an improvement on the current text, but we think it is also important to mention timezones. We feel that this is more important than the points raised in Comments #21 and #22.

For example, if I add two datetime-range fields, one with each option, then create a node setting both of them to the range May 8 to May 9, then this is what I see in the database:

MariaDB [db]> SELECT * FROM node__field_all_day_range\G
*************************** 1. row ***************************
                       bundle: page
                      deleted: 0
                    entity_id: 20
                  revision_id: 78
                     langcode: en
                        delta: 0
    field_all_day_range_value: 2026-05-08T04:00:00
field_all_day_range_end_value: 2026-05-10T03:59:59
1 row in set (0.000 sec)

MariaDB [db]> SELECT * FROM node__field_date_range\G
*************************** 1. row ***************************
                    bundle: page
                   deleted: 0
                 entity_id: 20
               revision_id: 78
                  langcode: en
                     delta: 0
    field_date_range_value: 2026-05-08
field_date_range_end_value: 2026-05-09
1 row in set (0.000 sec)

The all-day range goes from 12 AM on May 8 to 11:59:59 PM on May 9 in my timezone (America/New York, currently UTC-4 thanks to DST). That gets saved in the database as 2026-05-08T04:00:00 to 2026-05-10T03:59:59. If @rkoller (UTC+2) views my event, then it will appear as 6 AM on May 8 to 5:59:59 AM on May 10.

We do not have a recommendation for the exact wording, but we suggest adding examples based on the current date and time. For example, it might look something like this (assuming the current time is 15:44 in UTC-4):

• Date and time: stored as UTC timestamps (Example: 2026-05-09T19:44:00 to 2026-05-09T20:44:00)
• Date only: stored as dates (Example: 2026-05-09 to 2026-05-10)
• All day: from midnight in the current user's timezone to one second before midnight (Example: 2026-05-09T04:00:00 to 2026-05-11T03:59:59)

That ends up being a lot of text. Maybe it would be better to show only one line (without the initial label) depending on the currently selected option.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Thanks for the write up @benjifisher! One brief addition about the micro copy , in the current state the micro copy is also sort of redundant. You first have the option label in the select and then the same label again in the description (which is currently necessary to distinguish the three lines) and then the first two descriptions are more or less repeating the same for a third time; for date and time that the date and time is stored and for date only that only the date without the time is getting stored.

There is one other detail to note that i forgot to test during the meeting. If you are interacting with the select with a screenreader active (voiceover in my case), there are two additional noteworthy details and one question that comes up (check aural_interface.mp4):

• The helptext ("These settings apply to the Rang field everywhere...") is getting announced when the select element gets into focus, but the paragraph element wrapping that help text isnt programmatically linked to the select element. While the description aka the unordered list that is programmatically linked via aria-describedby is not getting announced - probably because entire unordered lists cant be linked at once
• If you then navigate ahead with the voiceover cursor / stepper, the bullet points are getting announced as well which is sort of noise.
• And the one question i ask myself; we came up with the suggestion in #23 to only show one single description for the option that is currently selected. It would have to be tested in different screenreaders if the dynamically changing description is reannounced on every change of the option.

And finally I've noticed one odd behavior in focus management with voiceover active (which is out of the scope for this issue). As illustrated in change_field_type.mp4, the select element gets into focus, you then change the default option to one other option (but with the select still in focus), when you then change the option for a second time the focus on the select is getting lost and moved to the Change field type button - without voiceover active the focus remains on the select element (*the problem in the striked section i am unable to reproduce anymore - initially ran into it in safari, then tried in firefox and edge where i was unable to reproduce, and when i revisited in safari i was unable to reproduce either - but before it was consistently changing the element in focus).

Hello,
I've updated my code to reflect your feedback. You'll find the new descriptions in the images below. I've modified the functionality so that the specific description appears only for the selected type, and I've revised the wording to include examples.
However, there is still a question regarding the examples. For now, I have stuck with static examples. I wonder if it might be better to use dynamic examples, even though that would require more resources each time the form is generated.