3 ms·

I'd much rather use the provided <input> types, like a normal UI program. That's less Kb sent, and hopefully better integration. I tried this, it's just that lo

by yyyk 5y ago

I'd much rather use the provided <input> types, like a normal UI program. That's less Kb sent, and hopefully better integration. I tried this, it's just that locale autodetection simply wasn't reliable enough. For example, one customer had all their computers default to MM/DD/YYYY despite locale using DD/MM/YYYY (and all other non-browser programs using the right format). So I ended up switching to js pickers thanks to the bad experiences. >instead of replacing everyting with your self-built thing There are about a million different js datetime pickers which provide the entire thing in a package, rather than me writing it all by hand.

berkes 5y ago
> I tried this, it's just locale autodetection simply wasn't reliable enough. Which was one reason they removed it from the spec. And why datetime-local does not have it. And why adding a simple <input type=hidden name=tz value=""/> can be filled by your JavaScript that detects the timezone. Or, if you need, a <select> or something else.
- yyyk 5y ago
  This helps with the timezone, but doesn't solve the format problem. If the browser decides 1/2/XXXX is 2nd Jan and not 1st Feb because locale detection went haywire, I can't know what the user really meant. Besides, once I need to write js it's just as easy to pull a datetime picker and use that... I'd like to use <input>, but they need to make it work and also allow a reasonable way of overriding the autodetection.
  - berkes 5y ago
    Did you even look at the spec for "datetime-local"? > One thing to note is that the displayed date and time formats differ from the actual value; the displayed date and time are formatted according to the user's locale as reported by their operating system, whereas the date/time value is always formatted YYYY-MM-DDThh:mm. When the above value submitted to the server, for example, it will look like partydate=2017-06-01T08:30.
    - 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.

by yyyk 5y ago

berkes 5y ago

> I tried this, it's just locale autodetection simply wasn't reliable enough. Which was one reason they removed it from the spec. And why datetime-local does not have it. And why adding a simple <input type=hidden name=tz value=""/> can be filled by your JavaScript that detects the timezone. Or, if you need, a <select> or something else.

yyyk 5y ago
This helps with the timezone, but doesn't solve the format problem. If the browser decides 1/2/XXXX is 2nd Jan and not 1st Feb because locale detection went haywire, I can't know what the user really meant. Besides, once I need to write js it's just as easy to pull a datetime picker and use that... I'd like to use <input>, but they need to make it work and also allow a reasonable way of overriding the autodetection.
- berkes 5y ago
  Did you even look at the spec for "datetime-local"? > One thing to note is that the displayed date and time formats differ from the actual value; the displayed date and time are formatted according to the user's locale as reported by their operating system, whereas the date/time value is always formatted YYYY-MM-DDThh:mm. When the above value submitted to the server, for example, it will look like partydate=2017-06-01T08:30.
  - 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.