4 ms·

First things first: The scope of this control is to let you pick a time, the hour and the minute of a day. Possibly from a native widget (i.e. on mobile it pops

First things first: The scope of this control is to let you pick a time, the hour and the minute of a day. Possibly from a native widget (i.e. on mobile it pops up a clock where you have to select an hour and a minute). It is then submitted without a timezone, not +0, just without. The timezone is simply out of scope for this, and with good reason: Presumably the time a user enters will be interpreted in one of two ways: * A javascript application running in the users browser, which already knows what the users current timezone is. * An application running on a server somewhere, which will have the information of "a user submitted a time without a timezone", which is valuable information and very often that is exactly the correct way to interpret a time. In the case very it's absolutely necessary to know the exact timezone a user wants to specify, it's very easy to add a widget to let a user specify the timezone. But I feel that's something that is much, much less common than letting a user set a simple time, so it makes sense to optimize for that.

mattmanser 9y ago
First things first: I'm talking about the date picker The time picker has it's own problems, like the Oh, So Useful! seconds part. And that most people use drop-downs for this, but they say entering a time by hand is better (when it's not). A lot of my client work at the moment is within the entertainment industry where obviously we need to pick times all the time. Both startups I work with use hour dropdown, [00, 15, 30, 45] minute drop down. One uses 24 h, one uses an AM/PM dropdown. You don't want people typing 12:07:03. That time picker is not fit for purpose and I wouldn't be able to use it. (Also, you don't seem to acknowledge this is a form control and you shouldn't need to use javascript to muck around with it before submitting it).
- krzyk 9y ago
  For me entering time by hand is easier then using a mouse and a picker, so it varies.
- yosamino 9y ago
  > First things first: I'm talking about the date picker But then why are you complaining about the timezone ? A datepicker doesn't need a timezone. Or are you under the impression that ISO 8601 requires a Time component? In case you are, you are mistaken: ISO 8601 requires no Time. "2017-10-23" is perfectly valid according to ISO 8601 and it's also precisely what is submitted by the browser. I don't really understand your comment about the specific allowed time format. It's obvious that every application will have different validation- requirements, that doesn't negate the usefulness of having a dedicated time input. Especially on mobile, getting a simple native time input widget seems like an advantage for many cases. If it doesn't work for your use-case then just don't use it. It exists to support, and if you already have a solution that is better, that's good, no? EDIT-start I wrote this next part not realizing that the UI for the timepicker is not enabled in this version of Firefox, please ignore. But just for completeness sake, you can let users enter increments of [00, 15, 30, 45] like this: <input type="time" name="time" step="900" /> The value 900 comes from 15 times 60 seconds. EDIT-end As for your comment about my mention of javascript, I think you overread that I wasn't advocating "mucking around" I was merely pointing out the context of a serverless javascript application.
  - mattmanser 9y ago
    It doesn't require it, that's the ambiguity. Damn, I find you frustrating. Are they just sending yyyy-MM-dd or are they adding 00:00:00. Or worse 00:00:00Z. Or even worse 00:00:00+0700? They don't say! It's the most important functionality of the date picker and the author, who was probably the developer, seems unaware of how critical spelling out the exact response type is. We're talking about a FORM control, a fundamental HTML technology that doesn't need JavaScript enabled. We're talking about specific implementation of a spec that they didn't spell out, skip over as if it didn't matter, and could alternately make the control brilliant or utterly useless. And no, it's not good that they add an inflexible, broken, time control that you have to type and almost no-one will be able to use. Because now they won't try and make a decent one.
    - LukeShu 9y ago
      > Are they just sending yyyy-MM-dd Yes! If they say that a date is to be in the ISO 8601 format, a reasonable person would assume that this means the ISO 8601 date format. > or are they adding 00:00:00. Or worse 00:00:00Z. Or even worse 00:00:00+0700? No! That would be the ISO 8601 datetime format! Why would you assume that they would use the datetime format for a date? > They don't say! If they said that dates are converted to RFC 2822 format, would you be griping about whether they were sending yyyy-MM-dd@hostname.tld? No, because it would be obvious from context that it means RFC 2822 date format, not RFC 2822 address format. Maybe there is a little bit of potential for confusion, because they say "All dates and times will be converted ...", rather than making separate statements for dates and times. But when they say "as specified in the [spec](hyperlink-to-the-spec)" 4 words later, a reasonable person might head over to that spec to clear up any confusion or questions about the behavior. > We're talking about specific implementation of a spec that they didn't spell out, skip over as if it didn't matter The did spell out the spec! They included a direct hyperlink to the spec; that link was even in the part that you quoted. And since when is a blog post expected to spell out every little thing that is included in the spec that it's talking about? Especially when every third paragraph says "as specified in the spec" with a link to the relevant page in the spec?

mattmanser 9y ago

First things first: I'm talking about the date picker The time picker has it's own problems, like the Oh, So Useful! seconds part. And that most people use drop-downs for this, but they say entering a time by hand is better (when it's not). A lot of my client work at the moment is within the entertainment industry where obviously we need to pick times all the time. Both startups I work with use hour dropdown, [00, 15, 30, 45] minute drop down. One uses 24 h, one uses an AM/PM dropdown. You don't want people typing 12:07:03. That time picker is not fit for purpose and I wouldn't be able to use it. (Also, you don't seem to acknowledge this is a form control and you shouldn't need to use javascript to muck around with it before submitting it).

krzyk 9y ago
For me entering time by hand is easier then using a mouse and a picker, so it varies.
yosamino 9y ago
> First things first: I'm talking about the date picker But then why are you complaining about the timezone ? A datepicker doesn't need a timezone. Or are you under the impression that ISO 8601 requires a Time component? In case you are, you are mistaken: ISO 8601 requires no Time. "2017-10-23" is perfectly valid according to ISO 8601 and it's also precisely what is submitted by the browser. I don't really understand your comment about the specific allowed time format. It's obvious that every application will have different validation- requirements, that doesn't negate the usefulness of having a dedicated time input. Especially on mobile, getting a simple native time input widget seems like an advantage for many cases. If it doesn't work for your use-case then just don't use it. It exists to support, and if you already have a solution that is better, that's good, no? EDIT-start I wrote this next part not realizing that the UI for the timepicker is not enabled in this version of Firefox, please ignore. But just for completeness sake, you can let users enter increments of [00, 15, 30, 45] like this: <input type="time" name="time" step="900" /> The value 900 comes from 15 times 60 seconds. EDIT-end As for your comment about my mention of javascript, I think you overread that I wasn't advocating "mucking around" I was merely pointing out the context of a serverless javascript application.
- mattmanser 9y ago
  It doesn't require it, that's the ambiguity. Damn, I find you frustrating. Are they just sending yyyy-MM-dd or are they adding 00:00:00. Or worse 00:00:00Z. Or even worse 00:00:00+0700? They don't say! It's the most important functionality of the date picker and the author, who was probably the developer, seems unaware of how critical spelling out the exact response type is. We're talking about a FORM control, a fundamental HTML technology that doesn't need JavaScript enabled. We're talking about specific implementation of a spec that they didn't spell out, skip over as if it didn't matter, and could alternately make the control brilliant or utterly useless. And no, it's not good that they add an inflexible, broken, time control that you have to type and almost no-one will be able to use. Because now they won't try and make a decent one.
  - LukeShu 9y ago
    > Are they just sending yyyy-MM-dd Yes! If they say that a date is to be in the ISO 8601 format, a reasonable person would assume that this means the ISO 8601 date format. > or are they adding 00:00:00. Or worse 00:00:00Z. Or even worse 00:00:00+0700? No! That would be the ISO 8601 datetime format! Why would you assume that they would use the datetime format for a date? > They don't say! If they said that dates are converted to RFC 2822 format, would you be griping about whether they were sending yyyy-MM-dd@hostname.tld? No, because it would be obvious from context that it means RFC 2822 date format, not RFC 2822 address format. Maybe there is a little bit of potential for confusion, because they say "All dates and times will be converted ...", rather than making separate statements for dates and times. But when they say "as specified in the [spec](hyperlink-to-the-spec)" 4 words later, a reasonable person might head over to that spec to clear up any confusion or questions about the behavior. > We're talking about specific implementation of a spec that they didn't spell out, skip over as if it didn't matter The did spell out the spec! They included a direct hyperlink to the spec; that link was even in the part that you quoted. And since when is a blog post expected to spell out every little thing that is included in the spec that it's talking about? Especially when every third paragraph says "as specified in the spec" with a link to the relevant page in the spec?