3 ms·

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

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?

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?