3 ms·
It's my fault. I mentioned timezones but the even bigger problem is client side formatting, so when I described that it was confusing two things. Imagine your
by yyyk 5y ago
It's my fault. I mentioned timezones but the even bigger problem is client side formatting, so when I described that it was confusing two things.
Imagine your screenshot instead of '12 - 06 - 2018' had displayed '06 - 12 - 2018'. For the same date (12th June 2018). Because locale detection failed it fellback to the US locale**. And it set up the input so that '06-13-2018' is legal but '13-06-2018' is not. Does my example make sense now?
In a JS datepicker, I could force DD/MM/YYYY (or whatever according to the user record) and that's it. Timezones are also a problem, but that's indeed easier to work around. The issue is that the specification by design does not allow forcing a format, despite me knowing exactly what the user wants.
It may sound fantastical that locale detection can fail that badly, but it did, and nothing simple I did could fix that - I don't exactly have access to set up the client machines, but I could reproduce on one of mine. Note that matheusmoreira here in this thread also has this problem, so it's apparently not impossibly rare.
Old Edge for example, seemed to prefer autodetection via the keyboard locale*** over the region date settings, and that was a product by the OS maker! (Also, their date picker was trash by modern standards).
** I guess all browser makers are American companies so US is default? Or perhaps it went to the US locale by keyboard like old Edge, since just about everyone here uses the English (US) locale for English.
*** Setting up English (UK) fixed the date display. Except that comes with other downsides.
- berkes 5y ago> In a JS datepicker, I could force DD/MM/YYYY (or whatever according to the user record) and that's it. This is the entire point of datetime-local. And why other native date fields were dropped and replaced by this one.
- yyyk 5y agoWe must be miscommunicating again or I'm being dimmer than usual, because when I read the spec and the MDN page I don't see any way of forcing the display format (pattern attribute exists only for browsers which do not understand the picker). I see 'browser will autodetect the right display format for the locale and give back YYYY-MM-DD' in so many words, which would be nice if it worked. The problem being it not actually working and not allowing me any good way to override it when it doesn't work. To be sure I wasn't imagining things, I decided to test again, with the simplest example I could find on the net (I forget w3schools still exists). https://imgur.com/a/XQWOfBk https://imgur.com/a/XQWOfBk Note the date format on the picker. I can assure the test system used had LANG, LC_TIME, LC_ALL, timezone, etc. all set to a non-American locale. I used Chromium to make sure this is on a typical(ish) browser. Still the MM/dd/YYYY format is used.