Replace date & date time picker widget with better alternative
See original GitHub issueIs your proposal related to a problem?
There are a lot of issues with Wagtail’s existing date / datetime picker implementation. This is a high-level issue to formalise our intention to replace it with a new implementation that should address some or all of those issues.
Issues under consideration:
Describe the solution you’d like
We’ll be selecting a UI widget for the calendar / time picker element as part of #7980. We’ll then have to integrate this well with existing Wagtail & Django APIs for date & time formats, and finally remove the existing implementation based on jQuery Datetimepicker, replacing it with the new one.
Describe alternatives you’ve considered
- Using the default
date
anddatetime
inputs - Releasing this new widget as an opt-in alternative rather than removing the existing.
- Releasing the new widget with a way to opt-out to the legacy widget for a few releases.
Additional context
Copying research from @allcaps shared on Slack:
Some notes about input formats, datepickers and internationalisation.
Locale aware input in forms
When formatting is enabled, Django can use localized formats when parsing dates, times and numbers in forms. That means it tries different formats for different locales when guessing the format used by the user when inputting data on forms.
https://docs.djangoproject.com/en/4.0/topics/i18n/formatting/#locale-aware-input-in-forms
DATE_INPUT_FORMATS
WhenUSE_L10N
isTrue
, the locale-dictated format has higher precedence and will be applied instead.
https://docs.djangoproject.com/en/4.0/ref/settings/#std:setting-DATE_INPUT_FORMATSThese are the Dutch formats: https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/conf/locale/nl/formats.py
According to this test, Dutch has some special time formatting rules (you may use a .
as separator).These Wagtail settings kill the Django fine-grained date(time) input handling.
https://docs.wagtail.org/en/stable/reference/settings.html?highlight=WAGTAIL_DATE#wagtail-date-format-wagtail-datetime-format-wagtail-time-formatTo make things worse, Django allows custom format files…
https://docs.djangoproject.com/en/4.0/topics/i18n/formatting/#creating-custom-format-filesI think, Wagtail date(time) inputs should follow Django: use Django to validate and convert the input string to date(time) objects. This allows the user to enter multiple formats, as long as it is an acceptable format for their locale. Django will convert any input format to date(time), if it can. Unfortunately this is a backend process. A JS datepicker should be aware of the Django current locale and use the correct display format and a preferred input format for the active locale. Django has JavaScriptCatalog for that…
The
JavaScriptCatalog
view
A view that produces a JavaScript code library with functions that mimic thegettext
interface, plus an array of translation strings.
https://docs.djangoproject.com/en/4.0/topics/i18n/translation/#module-django.views.i18n
get_format
Theget_format
function has access to the configured i18n formatting settings and can retrieve the format string for a given setting name:
document.write(get_format(‘DATE_FORMAT’));
https://docs.djangoproject.com/en/4.0/topics/i18n/translation/#get-format The SHORT_DATE_FORMAT
, SHORT_DATETIME_FORMAT
, and TIME_FORMAT
seem logical formats to use in JS picker enhanced inputs. But then we need to be sure that the values are also accepted by DATE_INPUT_FORMATS
, DATETIME_INPUT_FORMATS
and TIME_INPUT_FORMATS.
I’m not sure if that is guaranteed.Maybe it is better to format by the first value from DATE_INPUT_FORMATS
, DATETIME_INPUT_FORMATS
and TIME_INPUT_FORMATS
? I’ve got to investigate.An additional challenging scenario: If a user manually enters a date in an input, and opens the date picker, we expect the picker to highlight correct date. Again, the picker needs to understand the current locale formats (multiple). I’d suggest to create a simple Django view to accept a sting and return the iso formatted date.
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (6 by maintainers)
Top GitHub Comments
Interesting twitter thread on using native browser date pickers.
https://mobile.twitter.com/reinink/status/1507811705945997323
Added this as a likely scope item for the Stimulus RFC 78 project.