Date field elements have:
To have a consistent user experience when working with the date and time related elements (Widgets and Formatters)/
This is an epic and very long term plan. There are quite a few ways to categorise the tickets. Firstly by UX categories. Then by the sub-components of the date related core modules.
Formatting dates using the PHP method is non-intuitive.
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
There are slight differences between the datetime and timestamp widgets, but from the user's perspective the there shouldn't be.
Which format should we go with?
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
problems When on a browser that doesn't use the HTML5 inputs, there is no clear indication of what field is what, especially w/o the polyfill, b/c the labels are invisible
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
"Error messages aren't great" - In some cases these are just plain wrong. E.g. the date might be dd/mm/yyyy and the error message tells you to put you yyyy-mm-dd.
Field/s
Widgets
Formatters
Field/s
Widgets
Formatters
Field/s
Widgets
The date range widget should leverage client side validation to help prevent end is less than start
Formatters
Field/s
Widgets
Formatters
Active
11.0 🔥
Last updated
Makes Drupal easier to use. Preferred over UX, D7UX, etc.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This is great, thanks! I recently proposed a date standard in #3467914: Define a standard for Date formats → and 📌 Use ISO 8601 format in Authored on field date picker Active after the human readable Drupal core date formats were updated in 📌 Use easily recognizable date format RTBC . Perhaps defining a standard could help this issue move forward?