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.

Applying the change and does appear feedback is addressed @benjifisher could we remove the usability review tag?

Usability review

We discussed this issue for a second time at #3592720: Drupal Usability Meeting 2026-06-19. The link to the recording: https://www.youtube.com/watch?v=8fuVN9kiZ1c&t=11s.The attendees at the usability meeting were: @benjifisher, and @rkoller.

Thanks to @pcharrat for working on the MR and incorporating the feedback in #23! We have taken another look at the current state of MR15387 and there are few more details to note.

In regard to the question in #25, we still think having dynamic examples based on the current date (and time) would make the examples more clear in particular for the Date and time date type.

We've discovered several problems in the context of accessibility, for one with the MR checked out, but also already within the main branch. The problem for core in general, if you are interacting with a select element within a dialog modal by keyboard with VoiceOver enabled, as soon as you are trying to expand the option list of a select element for a second time by pressing the space bar the focus jumps to the Change field type button - that is not in line with WCAG 2.2 SC3.2.1 (jumpy_focus.mp4 - recorded with the main branch checked out) but clearly out of the scope for this issue, it should be solved in a dedicated followup issue.
In addition to that, the dynamic change of descriptions for the selected select element option are communicated in a confusing and misleading manner within the aural interface. In voiceover.mp4 (recorded with MR15387 checked out), first the label of the active option and its corresponding description for the select element are being announced, including the title of the field set (Field storage) and its help text, then the label of the active option and its corresponding description are announced a second time, and finally also the allowed number of value's active option and the chosen value are being announced in one go. If you then change from the date type Date and time to Date only the description for the Date and time date type is announced another time, plus the element is now announced as dimmed aka disabled which is not true. At this point the core bug illustrated in jumpy_focus.mp4 kicks in. But you can see in the following that the correct description was only announced for the default option when the dialog modal was opened for the first time, in the following it looks like always the description of the previous choice is being announced. The question is, is the cause for this misbehavior rooted in Drupal core or VoiceOver - as a first required step it would be important to test the MR in Jaws, NVDA, Orca, and or any other screenreader solution - I am adding the Needs accessibility review tag for that reason, and also to get few more pair of eyes onto that matter.

In regard to the micro copy, aside using dynamic example based on the current date (and time) we would recommend the following changes to the descriptions:

For Date and time
Stored as UTC date and time values (Example: 2026-05-09T19:44:00 to 2026-05-09T20:44:00).

For Date only
Stored as dates only, with no time values (Example: 2026-05-09 to 2026-05-10).

For All day
Stored as a full-day range in UTC, from midnight to 11:59:59 PM in the current user's timezone (Example: 2026-05-09T04:00:00 to 2026-05-11T03:59:59).

We are basically denote that timezones are being minded by Drupal and in what timezone date and time are being stored - a piece of information a user usually has no touchpoint with in the admin UI necessarily. That detail is relevant to Date and time and All day date types, while we've dropped the mention of timezones for the Date only date type.
In regard to consistency, we've also realized that the date type descriptions on the datetime field type are completely generic and not helpful at all. At the moment you have the same description Choose the type of date to create. for every date type option on the datetime field. Our recommendation would be to either extend the scope for this issue or open up a followup that should go into core, alongside with this issue ideally. It should be avoided having two different sets of descriptions, cuz datetime fields have the same two date types, Date and time and Date only, as the Datetime range. The only difference, the descriptions for datetime require singular forms, while the descriptions for Datetime range require plural forms. So in consequence our recommendation for the extended scope/followup for the date types on the datetime field type are:

For Date and time
Stored as UTC date and time values (Example: 2026-05-09T19:44:00).

For Date only
Stored as date only, with no time value (Example: 2026-05-09).

I've removed the "Needs usability review" tag and updated the User interface section by adding headings for before and after for an improved readability and comprehension.

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

I've updated the static wording to match the feedback from #28.
At this stage, I have two questions before going further:

1. Should the scope of this issue be expanded? The latest feedback also mentions the inconsistency with the datetime field type descriptions. Do you want this issue to evolve into a broader update of all date type descriptions, or should it remain limited to datetime_range and leave the rest for a follow-up issue?
2. Is a dynamic description actually desirable here? It would be possible to generate examples dynamically so that they better reflect the current date/time and timezone context, but that would also mean introducing additional logic using DrupalDateTime, DateTimeZone, and the current user timezone. I am not sure whether that is a good idea here.