(Circa end of 2021) Localization issues with input type=date?

[Carlton Gibson]

Hi all. 

There's a PR to add examples using `<input type=date ...>` for `forms.DateInput`. 

https://github.com/django/django/pull/14905

Support for HTML5 input types was added a long time back now in #16630.

Back then there were various issues with localisation when **not** using type=text. 

See https://code.djangoproject.com/ticket/16630#comment:11 and following discussion. 

The original mailing list thread is here.

The goal is to say something succinct but accurate that covers both sides of "Why the default is type=text" and "What you need to consider using type=date". 

Can we solicit some input (🥁) on what issues folks hit? — specifically for DateInput the concern was the required date format (I think). 

It may well be that things have changed since 2012? (If so we might revisit #21470.)

Thanks. 

Carlton

[Tom Carrick]

Hi,

It's true that the value is required to be in YYYY-MM-DD format, but in modern browsers (which I think is what we claim to support now, right?) it will show in the user's localised format. I checked this in Firefox, Chrome, Edge, and they all look good to me - they come with both a date picker, and allow you to enter the date in your local format. So I think the time has come where this might be a beneficial change (for #21470). However, Firefox is lacking a picker for <input type="datetime-local"> until the next version, though presumably that will be released before any change here would make it in.

Probably the problem here is that if we make this the default, we will break people's code who are not explicitly rendering their forms.

It also might be nice to use these in the admin and remove our own date picker code, if it doesn't pose any problems.

I realise this isn't actually an answer to your initial question, though.

Cheers,

Tom

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16d05604-4068-4423-9ac4-f8f520d44a42n%40googlegroups.com.

[אורי‎]

Hi,

I'm using a JS datepicker on https://en.speedy.net/ since 2017 and it works fine. It works both in English and Hebrew (which is RTL). I never found a need to use anything native to Django or browsers since the JS datepicker I'm using is great. I can customize the visible date format in each language and the names of the months. In the background it uses a hidden input in YYYY-MM-DD format.

אורי

u...@speedy.net

[Tobias Bengfort]

> Back then there were various issues with localisation when **not**
using type=text.

As https://code.djangoproject.com/ticket/16630#comment:11 states: the
inputs only accept a special format. To make it work I had to explicitly
set the format: `DateInput(format='%Y-%m-%d', attrs={'type': 'date'}`.

Another thing to be aware of: The native date picker UI uses the
system/browser locale, not the one that is used on the page. (See also
https://bugs.chromium.org/p/chromium/issues/detail?id=263320)

Hope that helps

tobias

[Carlton Gibson]

Thank you all, yes — there's some good points there. (Some others raised on the PR and the ticket too.) 

It's looks like there are still some caveats, and describing those succinctly remains to do. 

👍

Kind Regards,

Carlton

[Denny Biasiolli]

Hi everyone,

I just arrived on this topic searching for ideas about improving the admin datetime format.

I noticed that datetime values are passed between to/from the admin form using the format defined in settings, but as you mentioned, this could be a problem when users from different timezones are using the admin interface.

I'd like to contribute to this, and I can suggest to use an iso format (used in input type "date", "datetime-local" and "time") to pass data, so all formatting problems can be avoided.

My idea was to change the `localize_input` function to return `value.isoformat()` when `isinstance(value, (datetime.datetime, datetime.date, datetime.time))`.

After this we can customize the attrs of `AdminDateWidget`, `AdminTimeWidget` (and eventually add a `AdminDateTimeWidget`)

passing the correct input type (`date`, `time` or `datetime-local`).

Any other idea?

[Carlton Gibson]

Hey Denny. 

Thanks for looking at this! 

> My idea was to change...

Can I get you to put that into a (draft) PR on GitHub? It's much easier to think about with code in hand. :) 

Kind Regards,

Carlton

[Denny Biasiolli]

Hi Carlton,

Here we go: https://github.com/django/django/pull/15806

Just a draft for now, tried on a local Django project with a test model using Date, Time and DateTime fields.

I'm thinking to backward compatibility for custom admin templates, any thoughts?

Thanks

Denny

[Carlton Gibson]

Thanks Denny. 

I'll follow-up on the PR. Let's see what folks have to say. 

👍

Kind Regards,

Carlton

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/59eeae49-9670-4276-8543-fa93e85a86b0n%40googlegroups.com.

[Jacob Rief]

How about ditching the JS based datepicker altogether and replace it against the built-in datepicker offered by modern browsers? This would also help users of mobile devices because they already have good internal implementations to select a date. I agree that on desktop browsers the built-in datepicker does not really look nice, but IMO still works way better than the <input type="text"> widget, (ab-)used for date types as currently implemented in Django. 

A compromise for the Django Admin could be to detect the CSS query "@media (pointer:coarse)". If this matches, it's a mobile device and we can fall back on the internal date selector. Otherwise use a nice looking JS implementation.

There is a good article on CSS Tricks about date input types:

https://css-tricks.com/better-form-inputs-for-better-mobile-user-experiences/#aa-a-quick-detour-into-date-types

Btw., since PR#15806 is stale, may I reclaim it?

– Jacob

[Matthias Kestenholz]

Hi,

On Thu, Nov 10, 2022 at 9:40 AM Jacob Rief <jacob...@gmail.com> wrote:

How about ditching the JS based datepicker altogether and replace it against the built-in datepicker offered by modern browsers? This would also help users of mobile devices because they already have good internal implementations to select a date. I agree that on desktop browsers the built-in datepicker does not really look nice, but IMO still works way better than the <input type="text"> widget, (ab-)used for date types as currently implemented in Django. 

I'll second this. I'm not sure about ditching custom date pickers on all public-facing websites (yet) but I think it's definitely a good idea for administration panels. I have had good success with this in the last years.

The problem (as much too often) is Safari. Safari only has proper support since 14.1, released only ~18 months ago (https://caniuse.com/input-datetime) I haven't removed the date-input-polyfill yet. That may be a reason to wait a bit, sad as it is.

 

Thanks,

Matthias

[natali...@gmail.com]

I have pinged the original author asking if they can continue, if they can't or do not reply in a few weeks, please do so!