
Date/Time Inputs Enabled on Firefox Nightly - abhinickz
https://blog.nightly.mozilla.org/2017/06/12/datetime-inputs-enabled-on-nightly/
======
greggman
I'm curious about Japanese support which I think goes beyond locale.

Japanese often uses 24 hour times like 18:00 vs 6:00pm and while I see you can
specify valid times in that format I didn't see how to get it to display 18:00
instead of 6:00pm.

In the forms on this page

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/in...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/time)

When I typed 20:00 it assumed that first 2 meant 2am and then jumped to the
minutes section as soon as I typed 2. Note: My system settings are set to use
24 hour time.

Worse, Japanese times are often in terms of the night before. So for example
if you look at movie times a movie playing at 1:00am Saturday morning is
listed as 25:00 Friday night.

I wonder if input type=time is probably going to cause more trouble than it's
worth

~~~
nonsince
One problem with internationalisation attempts is that most of the committees
that have control over these things are from the Americas or Europe and so
speak a Romance language natively and almost certainly speak English well (if
not natively). There is nowhere near enough input from languages and cultures
that might not fit European norms. There's a great article about a similar
problem in Unicode:

[https://modelviewculture.com/pieces/i-can-text-you-a-pile-
of...](https://modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-
cant-write-my-name)

~~~
Majestic121
24h clock is very common in France, and other European countries as well

~~~
jszymborski
French Canada as well, and probably other members of the francophonie.

------
snitko
It looks like the date is displayed in the US format mm/dd/yyyy which is, of
course, most unnatural to all other countries. Is this customizeable, or is it
automatically adjusted depending on the language preferences in the browser?
If it's the latter, it's not cool - my preferred language for the browser is
English, but I hate the US date display format with passion.

EDIT: oh I see, automatically adjusted, but not configurable. Bad choice it
is, then.

EDIT2: I mean, there are so many more better and easy solutions to that
problem. You could display a date with a month name in the selected language -
"Oct 1, 2017" \- or start with a year "2017-10-01" which would be instantly
recognizable by anyone regardless of the country.

~~~
maggit
That's an awful shame. I can't really see myself using this when authoring
websites as long as it has that behaviour. If I am authoring a Norwegian web
site, the date format must be Norwegian, regardless of the user's preferred
locale.

~~~
nkristoffersen
I build interfaces for Norwegian web applications pretty often. Why must the
date format be Norwegian? Obviously this is just the form field, you shouldn't
actually store the data as displayed. I typically store UTC/ISO strings for
all dates, but in this case I would store it in whatever format I needed (such
as the Norwegian format), regardless of what the format was on the form. Never
trust client-side, right?

~~~
NetMonkey
I build Danish self service web applications, and from my perspective I would
always want to control that date formats fits the displayed language.

Why must it then be in Danish? Because we would rather optimize for Danish
users who for some reason have gotten the wrong browser version / localization
settings and don't know how to change it.

An English speaking user would be much better served with a dedicated English
version than just the date format being correct - if they can overcome the
language barrier, surely they can overcome the date format.

------
gldalmaso
What is the reasoning behind the decision to not make localization
configurable?

Can we agree that some webpages and webapps have already make the decision to
control the locale through the app and not choose the environment default?

My OS and browser locale is pt-BR, but if for whatever reason I am not happy
with a pt-BR UX, which is often, I want to be able to change it on a case by
case basis.

For example, any documentation I look up, like say on MDN or AWS, I want to
see it in english and not a poor/incomplete translation. If I play a Star Wars
game on my browser or phone I do not want any translations, I want the
original terms like scoundrel instead of the translator's choice of terms.

It is already bad enough as it is for the reasons I pointed out, now we are
gonna have that same nightmare in forms as well?

Sure webapps that actually care will find a non standard way, as they already
do, but then we are not actually improving when in 2017 you have to load 3rd
party libs just to be able to choose the locale of a date input.

<input type=date> (environment default)

<input type=date locale="pt-BR"> (actual chosen locale)

Is that too much to ask?

~~~
jhasse
I wouldn't want websites to overwrite my locale setting like that.

~~~
Hussell
I want the content, number formats, date formats, map labels, etc. on my
website to all use the same locale. Date input widgets are no exception.

I can't afford to give full support to all locales (translation costs are
ridiculous), so detecting and supporting the user's locale seems to be
pointless unless they happen to be using one of the limited set I can give
full support to (en-CA and fr-CA in my case). It seems like a far better idea
to allow the user of my website to choose one of the supported locales, and
see everything in the same consistent format than to have a few input widgets
on each page decide to configure themselves based on the locale the browser
was compiled with.

Edit: also, consider testing. Am I supposed to download a bunch of variants of
Firefox to test my locale support?

~~~
jhasse
> I can't afford to give full support to all locales (translation costs are
> ridiculous)

Even if your page isn't translated I would still want the dates to be
localized. I understand English, but not the US time and date formatting.

~~~
Hussell
That's a problem we already deal with by having labels for the date inputs
which explain the expected format. This is especially necessary in Canada,
where until recently there was no recommended format, and the government
recommendation isn't even well known yet much less universally used. So,
depending on what part of the country you live in, you'll expect a different
date format, even though you're technically using the same locale.

So, to do what you want, I'd have to make different versions of all the
supporting documentation for each possible date format, and then get each
version translated.

Also, displaying the dates the user just entered in a different format is a
usability problem. (Users will complain. A lot.) So, if I did what you want,
I'd likely be asked to display all dates, everywhere on the site, in the
format the browser happened to be compiled with. This is possible for dates in
the database, but not so much for dates in static content like news releases.

Just to be clear: I have no objection to making it easy for a website to have
date input widgets which use the user's locale. I just want it to be equally
easy for a website to have date input widgets in a specific locale. For
example, how am I to make a website comparing date input widgets for different
locales?

~~~
jhasse
> So, to do what you want, I'd have to make different versions of all the
> supporting documentation for each possible date format, and then get each
> version translated.

??? I'd never said that I wanted a label explaining the date format for me.

> For example, how am I to make a website comparing date input widgets for
> different locales?

The input widgets return ISO 8601 regardless of the locale. Or what do you
mean?

------
yvoschaap
I think the idea behind a native datepicker for <input> fields is good. But
the fact I can't customize the design and UX of the datepicker interface, it
always ends up being replaced by some javascript library where I can.

Same goes for the <select> input. The native one is usually always replaced by
a custom designed one.

~~~
oliv__
Agreed. You should really be able to fully style those inputs with bare CSS.
Would make life so much easier!

~~~
majewsky
Okay, please write a proposal for how to select parts of this widget with CSS.
Remember, it must be compatible with all major browsers and across all
formfactors (mobile, desktop, 10-inch, automotive, etc.). I'll schedule an
appointment for a review in 2020, since I don't expect you to be finished
earlier than that.

~~~
dbbk
There are already ways to style native UI widgets, you can even style
scrollbars...

~~~
jhasse
Styling scrollbars isn't really supported in Firefox IIRC. I hope it stays
that way.

------
mattmanser
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
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
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).

~~~
yosamino
> 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
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
_> 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?

------
giancarlostoro
I know everyone's ticked off about the "US defaults" but it's released in a
development / testing browser, not the typical Firefox release. They'll likely
do adjustments based on feedback. I hope it becomes configurable. Definitely
easier than importing some external libraries though.

Given how this was setup in a nightly release they're very likely to start out
"a little broken."

Really glad this is finally being added, I'm sure there's other features some
of us wouldn't mind in HTML out of the box.

Update: Realized it's released on nightly not "Developer's" edition.

~~~
Flimm
I'm not sure it's true that they'll adjust to feedback. Chrome has already
shipped a similar feature, and it has identical problems, IIRC. I think it's
quite likely Mozilla will just ship whatever is closest to Chrome's behaviour,
regardless of user feedback.

~~~
482794793792894
Well, Firefox is not Chrome. Firefox usually supports things more completely
than Chrome, partially because that's just what they do, they safeguard
webstandards, so delivering a standards-compliant browser is a main-goal, but
in large parts also because the community will make Mozilla go the extra mile
with code contributions, if they don't do it themselves.

And a Mozilla dev, Manishearth, has commented above that he is in fact
currently looking into making it configurable.

------
dingo_bat
> Note that there is no picker for <input type=time>. We decided not to
> support it since we think it’s easier and faster to enter a time using the
> keyboard than selecting it from a picker.

I wasted about 2 minutes trying to figure out how to input seconds in the
embedded example. Turns out it was am/pm. Maybe the picker can be a simple
drop-down list.

~~~
gvx
I'm on Fx 56.0.1, but I already enabled the date/time functionality in
about:config (key: dom.forms.datetime).

I think you can enable the time picker by toggling
dom.forms.datetime.timepicker on. It's on for me, but it isn't the default.

------
finalfantasia
This feature has already ridden the release train (currently in 57 beta) [1]
and should be released with Firefox 57 next month.

[1] [https://www.mozilla.org/en-
US/firefox/57.0beta/releasenotes/](https://www.mozilla.org/en-
US/firefox/57.0beta/releasenotes/)

------
abritinthebay
I know “finally” is a tech cliche but it feels like this has been a REALLY
long time coming.

Very thankful we’re starting to see this work roll out!

~~~
lucideer
First released in Opera 10 in 2009, it seems odd that this feature would take
8 years to develop, considering the proliferate JS+DOM implementations in the
wild. I wonder what kept it.

~~~
abritinthebay
Priorities I guess...

~~~
user5994461
I'd say localization.

~~~
scott_karana
Judging by the lack of format customization and Gregorian-only support, I
doubt i18n was the delay. ;)

~~~
abritinthebay
To be fair - that covers all areas the ISO date format covers.

------
Yaggo
Nice, but why <input type="date"> expects U.S. format 'mm/dd/yyyy' instead of
native format used in my system?

If it falls back to default format, at least the default could little bit more
universal/stanard, e.g. 'yyyy-mm-dd'.

Edit: Even after switching my preferred language from English to Finnish in
browser settings, the format stays 'mm/dd/yyyy'. I'm using Finnish region in
my OS settings as well.

~~~
fnord123
Many english speakers use en_US by default since it's the thing that breaks
the least, so using the native format of the system is not useful. It should
use ISO-8601 (yyyy-mm-dd) unless someone explicitly sets it in
about:preferences.

~~~
Yaggo
> Many english speakers use en_US by default since it's the thing that breaks
> the least, so using the native format of the system is not useful.

Sorry, I'm not following you. Every application should use the format defined
in OS settings, that's the point of the system setting, why should browser be
an exception?

~~~
DiabloD3
Most people intentionally set their locale wrong, to en_US, because a lot of
apps simply do not have actual locale support, but try to do something when
presented with a non-en_US locale.

~~~
beejiu
I cannot remember an app that did not support dd/mm/yyyy format. It is the
_first_ thing a non-US English speaker will complain about.

~~~
Piskvorrr
dd/mm/yyyy is indeed what I'll complain about: that's as unclear as possible.
Did the author mean dd.mm.yyyy or mm/dd/yyyy?

~~~
cyphar
DD/MM/YYYY is more widely used than the US-only MM/DD/YYYY. Ultimately, ISO
8061 (YYYY-MM-DD) is the only really usable one.

~~~
Piskvorrr
Nope, you're thinking of DD.MM.YYYY - using the USian separators with the
European date ordering is a recipe for trouble. Agree on the ISO form.

~~~
cyphar
We use DD/MM/YYYY in Australia. I can definitely agree that it adds to the
confusion. ;)

------
oliv__
OMG this feels like it should have been here AGES ago! Would have saved a lot
of pain and jquery-plugin problems...

Great to see it here! I hope it spreads to other browsers quickly.

~~~
kkarp
> I hope it spreads to other browsers quickly.

It is in other browsers for years

~~~
reustle
Except Safari iirc :(

~~~
robin_reala
Or IE11: [http://caniuse.com/#feat=input-
datetime](http://caniuse.com/#feat=input-datetime)

------
mdf
This is very nice, but the system LC_TIME locale (and whatever the equivalent
is on Windows) exists for a reason. I hope Mozilla will listen to the feedback
in all these comments and consider basing the picker type on the system time
locale – not on the language locale, and certainly not on the locale of the
downloaded binary.

I use most if not all software in English, but I prefer seeing dates in the
ISO format, weeks starting from Mondays and times in a 24 hour format.

~~~
idbehold
Does having your weeks start on Monday get confusing at all? I guess I'd just
find it weird to have Thursday be the middle of the week instead of Wednesday.
I also just find dates weird in general since it seems to use 1-based indexing
whereas time uses 0-based indexing. First month and day of new year? 01-01.
First hour, minute, and second of new day? 00:00:00.

~~~
mdf
> Does having your weeks start on Monday get confusing at all? I guess I'd
> just find it weird to have Thursday be the middle of the week instead of
> Wednesday.

Quite on the contrary! Wednesday is still in the middle of the working week,
leaving the two day weekend kind of as a special separate thing. :)

------
saagarjha
TIL you can render HTML from your address bar:

data:text/html, [Your HTML here]

~~~
lucideer
You can also render any format, including binaries, by base64 encoding the
file contents.

data:text/html;base64,[Your base64 encoded HTML here]

data:image/png;base64,[Your image data here]

The latter is extremely common for embedding static resources directly into
HTML pages. To the point there JS APIs the form obj.toDataURL()[0]

[0] [https://developer.mozilla.org/en-
US/docs/Web/API/HTMLCanvasE...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLCanvasElement/toDataURL)

~~~
oneeyedpigeon
> The latter is extremely common for embedding static resources directly into
> HTML pages.

What's the benefit of this? I get that it reduces the number of HTTP requests,
but it also fails to cache the resources, so you're betting on the client
never requesting that image again (and the client may be a proxy server,
right?). It also makes a right mess of your markup, if that's something you
care about.

~~~
Xophmeister
They can be embedded within a resource that is cached (e.g., an HTML page or
CSS stylesheet).

~~~
majewsky
For an example, see the SVG icons embedded in this CSS: [https://fsfw-
dresden.de/theme/css/fsfw.css](https://fsfw-dresden.de/theme/css/fsfw.css)
(search for ".logo-twitter", for example)

------
claudius
Hopefully it will stop people implementing their own date/time pickers which
only allow changing that date/time by clicking up/down arrows. In particular
the Munich transport website (mvg.de) is guilty of this and I absolutely hate
it with a passion.

~~~
majewsky
Of course it won't. Public service providers in particular need to provide
compatibility down to the likes of IE 7.

~~~
yosamino
To be fair, there would be a relatively easy way to test for support to
implement a fallback.

    
    
      var el = document.createElement("input");
      el.type = "time";
      var supported = (el.type == "time");
    

If only there wasn't a bug on firefox mobile that would return "text" even if
the input field type is supported.

... mhmmm webdevelopment...

------
ourcat
I wonder if this had anything to do with Microsoft, Google, Mozilla, etc.
recently deciding to consolidate web documentation at MDN.
[https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-
micr...](https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-microsoft-
google-w3c-samsung-together-create-cross-browser-documentation-mdn/)

Since I recently tried to implement a date input and was shocked to discover
that Firefox didn't support it, despite being in 'their' docs.
[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/in...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/date)

~~~
_Microft
Every article (where applicable) should have a browser compatibility section
near the end of it. (It's not such a new thing though)

In your case:

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/in...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/date#Browser_compatibility)

------
ajnin
One of the date examples shows a box with "06/09/2016" in it, with an error
popup which says "Please select a valid value. The two nearest valid values
are 2016-06-06 and 2016-06-11".

Seems incoherent to use US date format for the box and ISO8601 format for the
error message.

Also I wish software in general would stop trying to guess what the locale
settings should be and just ask. I have my language set as en_US but I prefer
to use 24h time and ISO8601 dates. With this update Firefox guesses wrongly
12h time and mm/dd/yyyy date format with no way to override it that I could
find.

------
482794793792894
> Note that there is no picker for <input type=time>. We decided not to
> support it since we think it’s easier and faster to enter a time using the
> keyboard than selecting it from a picker.

I've thought this so many times, even on my phone where typing is less
accessible, I still prefer it over those analogue clock face inputs.

With such a clock input, I'll often hit the wrong time, either an hour/minute
too late/early, due to my apparently fat fingers, or 12 hours wrong, because I
live in a 24-hour-format region where normally on an analogue clock you read
things in 12-hour-format and so my brain thinks "8 pm" and enters "8" when it
should have chosen "20". That doesn't happen with typing, because digital
clocks almost always display 24-hour-format.

And even worse, in an attempt to speed things up, someone came up with the
ingenious idea of directly advancing from hour input to minute input as soon
as some input has been made. So, my first few wrong inputs then mean that I
have to find the way to get back to the hour selection multiple times.

------
ComputerGuru
We've been using this in a corporate webapp for over two years in a Chrome
environment. I can't believe Firefox is only just getting this. You'd think
basic form inputs would have a UI this late in the game without needing to
pull in something like jQuery UI or similar.

Especially given how hard it is to implement dates and calendars correctly.

------
amelius
Nice, but their design doesn't match my website's design.

~~~
miguelrochefort
This right here is one of software's biggest problem.

Businesses have the hubris of designing their own custom UIs for everything,
deeply tainted with their branding, and they all end up reinventing the wheel
because standard solutions aren't compatible with their designs.

It's time to dissociate software from branding, so we can free 90% of
developers and have them do something useful for once.

~~~
amelius
> It's time to dissociate software from branding, so we can free 90% of
> developers and have them do something useful for once.

And how should we do that? Isn't that what CSS tried to do (but failed)?

Perhaps we should invent a different title for programmers that do relatively
simple work, like writing CSS and perhaps some easy javascript. That way, the
real programmers can more easily say "that's not in my job description".

~~~
miguelrochefort
I don't want software to be branded at all.

I want all apps to look and behave the same, to the point where they're all
just one app.

Nobody asked for their shopping experience to be different when shopping on
Amazon vs eBay vs Craigslist. I see no compelling reason to have different UI
for services that are essentially identical.

~~~
felipeko
So, who gets to decide what it all look like? The broswer vendor? W3C?

What if one browser does something others won't, and you can't do it custom,
how do you get around it? Wouldn't that put us back to IE6 web?

What if your site really needs something browsers don't have? Will we have
sites telling us to install a plugin and put us back to Flash era?

~~~
miguelrochefort
Every browser will be opinionated and render things differently.

Custom things will be done through a canvas, but that should only be used in
last resort.

~~~
amelius
Ok, but you can already do that.

Or do you want to enforce it somehow?

~~~
miguelrochefort
We first need data to be distributed in a way that preserves semantics (i.e.,
not HTML).

------
ComodoHacker
Side note: I was trying to think up a viable case for applying @step attribute
to date input but quickly gave up.

~~~
brucen
If something runs weekly (e.g., every Saturday), it could be useful to verify
the user has picked a Saturday. Not sure if the dropdown would grey out other
days too, as that could be useful to be able to remove unavailable days.

~~~
mattmanser
You generally want the converse, the ability to block off Saturdays and
Sundays.

~~~
brucen
Depends on the application obviously. A lot of social groups would likely be
meeting once a week. It's just a simple example though of how the step
function could be useful.

For your example, you would just need a step with some kind of range. So you
could say step=7, range=5 to allow them to pick from the first 5 days of every
7 (or to get trick step=7 range=-2 to eliminate the last 2 days). I'd hazard a
guess they thought about this kind of stuff, but realised it would be
complicated pretty quickly.

~~~
mattmanser
Most applications are enterprise apps, the vast majority of apps in the world
today are enterprise apps. That work Mon-Fri, so want to restrict date pickers
to Mon-Fri.

And it doesn't have range, does it? So the infinitely more useful range hasn't
been specified, but the almost useless step has.

[https://html.spec.whatwg.org/multipage/forms.html#forms](https://html.spec.whatwg.org/multipage/forms.html#forms)

------
mullsork
Chrome has had this for what feels like years. Is there something new in there
or did Firefox just catch up?

Good news in any case! The back office tool I work on is Chrome only and it's
been great to just use type="date"!

~~~
gkya
I guess most of us saw it for the first time used in the url bar. It did
surprise me too altho I knew how they were used to embed images and such.

------
ape4
Any ideas on how a website should use this? Can you detect if input.date
exists easily (for the current browser) without resorting to checking the
brand and version of the browser?

~~~
kemayo
Modernizr detects supported input types:
[https://github.com/Modernizr/Modernizr/blob/master/feature-d...](https://github.com/Modernizr/Modernizr/blob/master/feature-
detects/inputtypes.js)

It's basically just making an <input>, setting its @type and seeing if that
sticks, then setting a known-invalid value and seeing if that sticks.

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

~~~
MattBearman
ISO 8601 (yyyy-mm-dd)

~~~
moogly
No timezone part? Or UTC (w/ Z)?

~~~
Manishearth
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
> 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

------
baxtr
Can somebody explain why this is big news? It looks like a standard input to
me. I'm genuinely asking...

~~~
wruza
Adding date picker to platform _after_ it lived through the peak of world-wide
application development is big news itself.

------
mixedCase
No week picker? Edge and Chrome implement it.

------
ptman
finally not only in chrome (and apparently opera)

------
Brosper
Finally? God why it to them so long to implement the most basic thing :(

------
pette
This is not newsworthy.

But will the inputs be mixed-reality ready?

------
mozumder
This is a nice start but we basically need a full API of these to match all
the widgets and view controllers you find in a full GUI environment like Mac
OS/Windows/iOS.

~~~
wruza
People who don’t give a fcuk about controllers and patterns outnumber
traditional folks heavily, so there is no place to look for understanding of
it today. Just wait and someday you’ll hear about Element Group Management or
whatever classic weathered MVC would be called then. Don’t miss that year
though, check regularily.

