Epic: Refactor and enhance UX of date and time-based components

[geospatialem]

Description

Refactor the design of our Date and Time-based components to include:

1. Support of new features
   • Individual month, day, year individual inputs: [Input Date Picker, Input Time Picker] Individual month, day, year individual inputs #8624
2. Better UX of the component(s)
3. More support for keyboard users
4. Refactored code base for us to maintain the component(s) in the future

cc: @eriklharper for additional considerations as we move towards design considerations.

Proposed Advantages

• Refactored component code for maintenance
• More component features/support
• Improved a11y support
• Improved UX

Which Component

• date-picker
• input-date-picker
• time-picker (possibly?)
• input-time-picker (possibly?)
• input-time (in progress)

Relevant Info

This came up in a Community idea to add a range to our input-time-picker component, and was discussed with other developers to determine some options for us as we move forward, both with Date picker and Time picker components.

Some other resources for UX consideration:

• MUI Date Range Picker component
• Base Web Datepicker component

[geospatialem]

Related: #3455

[eriklharper]

Here are some additional asks on our time input experience that we should incorporate into the design of this new experience:

Millisecond support: #6591
Timezone Offset support: #6590

I'll also include here some open bugs that showcase some of the pitfalls of the current experience:

The existing input-time-picker's design necessitates parsing a free-form input which is more complicated than a masked input experience that forces entry of only the numbers of the time value and the meridiem: #6398

This is a bug in Date Picker where clicking an end date after the existing end date of a date range won't change the end date: #6223

Here's a case where we would like to drop support for calcite-input type="time": #4756

This would be a nice improvement we could add as part of the masked input experience: #3671

Here's a big one that ties into our Validation story: supporting invalid states for when entered values are out of range or a required input is empty: #3526

[SkyeSeitz]

This is a part of the Date Picker Redesign epic #6721, but looks like this issue could possibly be its own epic that focuses on UX of both Date and Time Picker, allowing #6721 to be focused on just Date Picker whose remaining issues are all accounted for in this comment on the epic.
lmk what y'all think.
cc @geospatialem @eriklharper

[eriklharper]

This is a part of the Date Picker Redesign epic #6721, but looks like this issue could possibly be its own epic that focuses on UX of both Date and Time Picker, allowing #6721 to be focused on just Date Picker whose remaining issues are all accounted for in this comment on the epic. lmk what y'all think. cc @geospatialem @eriklharper

Sounds like it is a different "thing" than just a Date Picker redesign for sure. Feel free to remove this from the #6721 epic and we can treat this as a separate effort. Significant progress has been made on several of the items I addressed in that comment above too, to which I crossed off millisecond and time zone support. I'm currently making progress on input-time which addresses issues with the free-form input in input-time-picker. My goal is to get input-time shipped before the end of the year.

[geospatialem]

Removed from the #6721 epic, and leaving this one as a standalone to tackle across components.

[emmilaakso212]

@geospatialem would timezone picker enhancements be considered part of this epic? Just wanted to chime in since that's something I've been supporting with in collaboration with @ashetland . We don't have a ticket (to my knowledge) yet, but are requirements gathering and working with a wider group to determine best next steps.

[geospatialem]

@geospatialem would timezone picker enhancements be considered part of this epic? Just wanted to chime in since that's something I've been supporting with in collaboration with @ashetland . We don't have a ticket (to my knowledge) yet, but are requirements gathering and working with a wider group to determine best next steps.

@emmilaakso212 The input-time-zone component is not currently in scope for the epic, but cc'ing @ashetland for expertise to determine if it should be added to the effort.

[geospatialem]

Added input-date-picker and input-time-picker individual month, day, and year individual inputs to the above epic's efforts in #8624.