4 ms·

I know how it's transmitted, and that's totally fine. The problem is on the other end: The guarantee ("formatted according to the user's locale") too often doe

by yyyk 5y ago

I know how it's transmitted, and that's totally fine. The problem is on the other end: The guarantee ("formatted according to the user's locale") too often doesn't work, the displayed date and time format somehow may not match the locale as reported by the OS. In the previous example, users in EU countries can get a MM/dd/YYYY input despite the locale being set right. The user can enter a date thinking it's DD/MM/YYYY (some users preferred fast input with the keyboard), so what they send to the server is really YYYY-DD-MM despite the "guarantee" because the browser somehow doesn't understand how the date should be formatted on the client. Otherwise it was just extremely annoying to the users and to me, so it was the last straw for using <input> that way. I could hack it, but what's the point of maintaining a hack when there are many packages out there just implementing a picker?

berkes 5y ago
It appears we are either talking about something different or otherwise not understanding one another. Here's how the native datetime-local looks: https://i.imgur.com/7kNficu.png https://i.imgur.com/7kNficu.png How is that different from most or any JS frameworks with regards to DD/MM/YYY formatting? How can a user filling in a date, confuse "12 juni 2018" (juni Dutch locale for "June") with the 06-12-2018? And if so, how does any JS based datepicker solve this instead?
- 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 ago
      We 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.

by yyyk 5y ago

berkes 5y ago

It appears we are either talking about something different or otherwise not understanding one another. Here's how the native datetime-local looks: https://i.imgur.com/7kNficu.png https://i.imgur.com/7kNficu.png How is that different from most or any JS frameworks with regards to DD/MM/YYY formatting? How can a user filling in a date, confuse "12 juni 2018" (juni Dutch locale for "June") with the 06-12-2018? And if so, how does any JS based datepicker solve this instead?

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 ago
    We 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.