6 ms·

> 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 yo

> 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?

greggturkington 5y ago
Not gone, but that's the direction we're heading (hopefully). > 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/input/datetime-local https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- onli 5y ago
  I literally waited years for this. This year I opted to change a backend date input from datetime-local to date and time input input fields, after waiting too long for browser support. The datetime-local field got added 2014, "browsers will support it soon"...
- exyi 5y ago
  > Because of the limited browser support 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.
  - he_is_legend 5y ago
    1 year old safari. it was added april 2020 - https://caniuse.com/?search=datetime-local https://caniuse.com/?search=datetime-local
yyyk 5y ago
No, you still need a datetime picker. 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.
- matheusmoreira 5y ago
  > the user thought they were entering a DD/MM/YYYY date, while the browser decided it's getting MM/DD/YYYY 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?
- berkes 5y ago
  According to MDN[0], timezones are not supported. But easy to add on top of the native datetime-local field. So it looks like that timezone detection of yours is all you need: let it fill a hidden field, instead of replacing everyting with your self-built thing (which probably lacks aria controls, keyboard controls, breaks tabbing, looks terrible on dark-mode and so on). > ...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/input/datetime-local#setting_timezones https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
  - 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.
newhotelowner 5y ago
> does this mean the days of trying to find/create your own (good) datetime picker component are gone? It won't look and behave like how designers wanted in your company. It will look different in different browser and OS.
- makapuf 5y ago
  It will look and behave the same as other date time pickers on your os. It may benefit of better integration of your os. It might be more accessible.
  - newhotelowner 5y ago
    I personally prefer native date picker as user are used to the OS and browser. But designers, product managers prefer things they design.

greggturkington 5y ago

Not gone, but that's the direction we're heading (hopefully). > 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/input/datetime-local https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

onli 5y ago
I literally waited years for this. This year I opted to change a backend date input from datetime-local to date and time input input fields, after waiting too long for browser support. The datetime-local field got added 2014, "browsers will support it soon"...
exyi 5y ago
> Because of the limited browser support 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.
- he_is_legend 5y ago
  1 year old safari. it was added april 2020 - https://caniuse.com/?search=datetime-local https://caniuse.com/?search=datetime-local

yyyk 5y ago

No, you still need a datetime picker. 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.

matheusmoreira 5y ago
> the user thought they were entering a DD/MM/YYYY date, while the browser decided it's getting MM/DD/YYYY 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?
berkes 5y ago
According to MDN[0], timezones are not supported. But easy to add on top of the native datetime-local field. So it looks like that timezone detection of yours is all you need: let it fill a hidden field, instead of replacing everyting with your self-built thing (which probably lacks aria controls, keyboard controls, breaks tabbing, looks terrible on dark-mode and so on). > ...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/input/datetime-local#setting_timezones https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- 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.

newhotelowner 5y ago

> does this mean the days of trying to find/create your own (good) datetime picker component are gone? It won't look and behave like how designers wanted in your company. It will look different in different browser and OS.

makapuf 5y ago
It will look and behave the same as other date time pickers on your os. It may benefit of better integration of your os. It might be more accessible.
- newhotelowner 5y ago
  I personally prefer native date picker as user are used to the OS and browser. But designers, product managers prefer things they design.