4 ms·
> 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
by 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 agoIt 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?