> The UI for <input type="datetime-local"> has been added.
I've been out of frontend web dev for a while... does this mean the days of trying to find/create your own (good) datetime picker component are gone?
I've been out of frontend web dev for a while... does this mean the days of trying to find/create your own (good) datetime picker component are gone?
> it may currently still be best to use a framework or library to present these, or to use a custom input of your own. Another option is to use separate date and time inputs, each of which is more widely supported than datetime-local
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Which browser does not support it (if we can exclude IE 11)? And if some obscure browser does not support, it will just fallback to input[type=text], so no big deal. I'm really looking forward to get rid of all these JS implementations which can't properly handle keyboard / touch / screenreader / whatever comes.
That's because by design <input> does not let you configure a timezone (EDIT: nor a datetime format), and it's always somehow badly detected/misconfigured on a small subset of your users. Later you find out the user thought they were entering a DD/MM/YYYY date, while the browser decided it's getting MM/DD/YYYY, and hijinks ensue. It's easy to ensure the correct timezone on js pickers.
> ...the date/time and time zone values would be submitted to the server as separate data points, and then you'd need to store them appropriately in the database on the server-side.
Which, IMO is the correct way, also for a datetime-picker, anyway.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
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.
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.
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.
> 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.
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?
Here's how the native datetime-local looks: 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?
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.
This is the entire point of datetime-local. And why other native date fields were dropped and replaced by this one.
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).
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.
Happens to me every week. Sometimes nearly every day. It is infuriating. Why can't they use YYYY-MM-DD? When are we humans gonna stop having these problems?
It won't look and behave like how designers wanted in your company. It will look different in different browser and OS.
But designers, product managers prefer things they design.