4 ms·

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 som

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

by yyyk 5y ago

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