3 ms·

Statements like this show how ambiguity creeps in: All dates and times will be converted to ISO 8601 format, as specified in the spec, before being submitted t

Statements like this show how ambiguity creeps in: All dates and times will be converted to ISO 8601 format, as specified in the spec, before being submitted to the web server. Are you going to be appending a Z? Adding the browser's timezone? Adding T00:00:00Z to the dates? What? No clarity at all. You can't just hand wave and say 8601! 8601! Also, we've had date and time pickers for over a decade now and this clearly doesn't meet the need. It's such a shame that this is the standard they come out with.

yosamino 9y ago
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
> No clarity at all. You can't just hand wave and say 8601! 8601! No, but you can hand wave and say "as specified in the [HTML5] spec", with a link to the spec, and have the spec cover the details. But really the answer is: ISO 8601 specifies standard formats for both datetimes (what you are referring to), and plain dates (YYYY-MM-DD). When an article says that a date is converted to ISO 8601 format, isn't it obvious that it means ISO 8601 date format, not ISO 8601 datetime format? (Additionally, the spec doesn't say "8601 format", it specifies the format, and notes that it is "based on" 8601 format).

yosamino 9y ago

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

> No clarity at all. You can't just hand wave and say 8601! 8601! No, but you can hand wave and say "as specified in the [HTML5] spec", with a link to the spec, and have the spec cover the details. But really the answer is: ISO 8601 specifies standard formats for both datetimes (what you are referring to), and plain dates (YYYY-MM-DD). When an article says that a date is converted to ISO 8601 format, isn't it obvious that it means ISO 8601 date format, not ISO 8601 datetime format? (Additionally, the spec doesn't say "8601 format", it specifies the format, and notes that it is "based on" 8601 format).