4 ms·

But what format is the data sent to the server in?

by Zash 9y ago

MattBearman 9y ago
ISO 8601 (yyyy-mm-dd)
- moogly 9y ago
  No timezone part? Or UTC (w/ Z)?
  - Manishearth 9y ago
    No. It's up to the application to decide how it wishes to interpret timezones. Or if timezone should be a factor at all. E.g. if I'm booking a hotel you don't want it to pick up the user's timezone and frob that into UTC to send it over; you want the local hotel timezone. But if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that. Assuming all time fields must have a timezone is why e.g. jekyll will re-date your prior posts (breaking all URL slugs) when you change your timezone.
    - moogly 9y ago
      > if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that I suppose. In the product I'm current working, I guess technically we could add a TZ dropdown as you describe, but it'd go unused because the kind of events our users schedule, they want to use their current corporate local time always (there's no travelling across timezones involved for our users), and we need to know what time that is over here, so in lieu of one useful form field (UTC or datetime offset), we'd now have to send two (change the dropdown to a type=hidden), or another one with a "proper" datetime string. I guess not the end of the world[1], but it does introduce more opportunities for bugs. From what I've seen, few products have that timezone dropdown, and usually it tends to be an override that still needs a sensible fallback, and no information as to what timezone the current user is in gives you absolutely nothing. DateTime offset lets the application handle most cases, so that's what I prefer to use. [1]: also needs a timezone
bzbarsky 9y ago
For <input type="date">, it's a https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string https://html.spec.whatwg.org/multipage/common-microsyntaxes.... (see <https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)> https://html.spec.whatwg.org/multipage/input.html#date-state... though you have to know how the inputs section of the spec works in general to see that it enforces the "valid date string" constraint). To translate from spec to something readable, it's YYYY-MM-DD, with nothing else. For <input type="time"> it's <https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string> https://html.spec.whatwg.org/multipage/common-microsyntaxes..... Again, to translate to something readable, it's HH:MM[:SS] where the :SS part is optional if seconds is 0, and all numbers are 0-based (so 0 <= HH <= 23, 0 <= MM,SS <= 59). For <input type="datetime-local"> it's https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-normalised-local-date-and-time-string https://html.spec.whatwg.org/multipage/common-microsyntaxes.... which is yyyy-mm-ddThh:mm[:ss] without any timezone information, afaict, and with [:ss] guaranteed to be left out if 0.

But what format is the data sent to the server in?

by Zash 9y ago

But what format is the data sent to the server in?

MattBearman 9y ago

ISO 8601 (yyyy-mm-dd)

moogly 9y ago
No timezone part? Or UTC (w/ Z)?
- Manishearth 9y ago
  No. It's up to the application to decide how it wishes to interpret timezones. Or if timezone should be a factor at all. E.g. if I'm booking a hotel you don't want it to pick up the user's timezone and frob that into UTC to send it over; you want the local hotel timezone. But if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that. Assuming all time fields must have a timezone is why e.g. jekyll will re-date your prior posts (breaking all URL slugs) when you change your timezone.
  - moogly 9y ago
    > if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that I suppose. In the product I'm current working, I guess technically we could add a TZ dropdown as you describe, but it'd go unused because the kind of events our users schedule, they want to use their current corporate local time always (there's no travelling across timezones involved for our users), and we need to know what time that is over here, so in lieu of one useful form field (UTC or datetime offset), we'd now have to send two (change the dropdown to a type=hidden), or another one with a "proper" datetime string. I guess not the end of the world[1], but it does introduce more opportunities for bugs. From what I've seen, few products have that timezone dropdown, and usually it tends to be an override that still needs a sensible fallback, and no information as to what timezone the current user is in gives you absolutely nothing. DateTime offset lets the application handle most cases, so that's what I prefer to use. [1]: also needs a timezone

bzbarsky 9y ago

For <input type="date">, it's a https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string https://html.spec.whatwg.org/multipage/common-microsyntaxes.... (see <https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)> https://html.spec.whatwg.org/multipage/input.html#date-state... though you have to know how the inputs section of the spec works in general to see that it enforces the "valid date string" constraint). To translate from spec to something readable, it's YYYY-MM-DD, with nothing else. For <input type="time"> it's <https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string> https://html.spec.whatwg.org/multipage/common-microsyntaxes..... Again, to translate to something readable, it's HH:MM[:SS] where the :SS part is optional if seconds is 0, and all numbers are 0-based (so 0 <= HH <= 23, 0 <= MM,SS <= 59). For <input type="datetime-local"> it's https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-normalised-local-date-and-time-string https://html.spec.whatwg.org/multipage/common-microsyntaxes.... which is yyyy-mm-ddThh:mm[:ss] without any timezone information, afaict, and with [:ss] guaranteed to be left out if 0.