Date/Time Inputs Enabled on Firefox Nightly | Hacker News Reader

Date/Time Inputs Enabled on Firefox Nightly

blog.nightly.mozilla.org

265 pointsabhinickz201 comments

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

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

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

In this particular case though, 24 hour time is common in Europe and even in the US it's somewhat common (I use it). I curious how they could have overlooked it (partially).

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

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

I am from Denmark, so I am mostly used to dealing with 24 hour clocks, I know it is simple for others but AM/PM gets me so confused, we do not use the 25:00 format as you.

Now I live in the UK, and I still have to convert my friends to be using 24 hour clocks, maybe it will help if I start showing up at their houses at 05:00 instead of 17:00 :D

TV hours work the same in France, except that a movie playing at 01:00 on Saturday will be listed on Friday, at 01:00. In other words, the first item listed on a given day is at, say, 9:00 that day despite the fact that other things were played earlier. The TV day then ends at, say, 6:00 the day after.

I am not sure of the hours because I haven't actively watched TV for years but it was certainly the case when I was a kid in the 80's where TV was not 24/24 but ended sometime in the night. It was then natural for the next day to start at 9 or whatever was the earliest broadcast.

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.

At least on macOS it seems not to be automatically adjusted. It still displays me the illogical mm/dd/yyyy format, despite my Firefox having 'Finnish' on top in language settings.

Ideally the application should read the system regional setting and use that. For example, my macOS uses English as language and Finnish as region. (I've no idea if the system provides an API for reading regional settings, though.)

Confirmed.

The MacOS system, of course, provides APIs to get language and locale settings (for dates, number formatting, etc.) separately.

The JavaScript environment, on the other hand, doesn't really have any good APIs that properly separate preferred language from other things like units (metric vs. imperial), formatting dates and times, currencies, and so on.

I was hoping this would be an improvement to the state of JavaScript wrt. locales. Sadly, it looks like this build of Firefox Nightly still doesn't do dates correctly on MacOS, and this is just as broken as everything that came before it.

I have language, dates, number formatting, and everything set up just the way I like it in the OS settings, why the web/JS world just doesn't use those settings is beyond me.

> The JavaScript environment, on the other hand, doesn't really have any good APIs that properly separate preferred language from other things like units (metric vs. imperial), formatting dates and times, currencies, and so on.

You could implement the locale-less Intl.DateTimeFormat or Intl.NumberFormat such that they get the current formatting settings regardless of locale data.

Here's the problem: given that I have already configured date and time formats (among other things) in my operating system, like everybody else has, how do I access those settings and pass them on to DateTimeFormat?

> Here's the problem

The browser ought do that automatically, that it does not is the issue at hand. I was just pointing out that the Intl API does not seem to preclude implementing this behaviour, it still needs to be implemented. Which first means that it should be reported to Firefox's bug tracker (I have not seen a single link to FF's bugzilla in any of the subthreads).

Note that the format "2017-10-31" is also an ISO standard (ISO 8601), so when in doubt, this is the most sane default you can have.

Agreed. I personally use it everywhere I can because it makes it easy to sort anything that is date/time based.

From my experience people outside IT or science may not have recognize ISO format as a date. Using US ordering with a word for the month in the native language can be safer default.

I'm wondering how difficult (if not impossible?) it would be to change the format in the US.

It makes no sense whatsoever and the US seem to be the only place in the world to use mm/dd/yyyy excluding a few countries in Africa (and even there it's not the most popular format):

https://i.guim.co.uk/img/static/sys-images/Guardian/Pix/pict...

https://en.wikipedia.org/wiki/Date_format_by_country

Welcome to the world of middle endian.

And for this reason the ISO standard is yyyy-mm-dd, big endian just like writing numbers; and it sorts (numerically not lexigraphically) properly too!

It sorts lexigraphically if it is zero padded.

Only as long as you zero-pad the year according to the maximum year in your list.

I'll dub this "the year 10000" problem.

> I'll dub this "the year 10000" problem.

http://longnow.org/about/ "The Long Now Foundation uses five-digit dates, the extra zero is to solve the deca-millennium bug which will come into effect in about 8,000 years."

Long Now's use of five-digit years is also supposed to jolt readers and remind them to think in the bigger picture.

By the year 10000, hopefully terrestial time is long obsolete, and replaced with whatever makes sense for a multi-planet species.

Based upon human stubbornness, every planet will have it's own time and date system that will be divided based on historically obscure details before/during and after colonization. Stuff like Thursday is essentially "Thor's day" and in German it literally says "day of the thunder" (Donnerstag).

ps.: Thursday is also Jupiter's day, so it will probably prevail on any colony / permanent human station orbiting it/it's moons.

pps.: I hope they get over the stupid imperial vs. metric divide though.. that one is really annoying.

Interplanetary daylight savings could be a lot of fun too.

Assuming that is anyone left that cares about it.

I would expect that to be exactly as difficult as converting from Imperial to metric units in general, which has been a complete and utter disaster so far.

It makes sense because of the way that you say it. “January 1, 1970” == 1/1/1970.

Other formats don’t make sense.

That format of long-form dates is also an Americanism. For example, from the BBC Style Guide:

"Dates: Put the day before the month (eg: 12 April 2001)”

http://www.bbc.co.uk/academy/journalism/article/art201307021...

Ok, but so what? That doesn’t explain why anything else makes more sense.

>because of the way that you say it

Because of the way you say it in English?

English is the official language of the USA.

No, the US has no official language at the federal level:

" English is the official language of 32 states; English and Hawaiian are both official languages in Hawaii, and English and 20 Indigenous languages are official in Alaska. Algonquian, Cherokee, and Sioux are among many other official languages in Native-controlled lands throughout the country. French is a de facto, but unofficial, language in Maine and Louisiana, while New Mexico law grants Spanish a special status."

English is spoken by the vast, vast majority here. So it is the de facto standard language in the United States.

Nothing that you have said has explained why anybody should make a change to the date format.

Except that I say “The first of January 1970”

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.

> If I am authoring a Norwegian web site, the date format must be Norwegian, regardless of the user's preferred locale.

If I understand you correctly, this is something I strongly disagree with. Many people are bilingual if not more, so when I have two tabs from different sites I prefer the dates to be consistent. At least on my Linux machine I want those to be driven by my locale settings, which lets me choose UK English, US English or 50 other conventions if I so desire.

I routinely run terminals with different locales set on the same screen and I would like programs started from those not get smart about locale choices but rather do exactly as I ask. Just my poor user 2c.

Hm, I think we strongly disagree here.

I am bilingual myself, and I strongly prefer each context to be self-consistent. When reading English text I find Norwegian date formatting confusing, and vice versa. I routinely have open tabs in different languages.

Which is OK (so the user should have a choice :) ). Just my personal experience, but seeing dates as "06/07/20XX" always makes me do a double check (is this next week or in a month?) unless I know that I have everything configured my way, which may be different from the way of site designer.

That doesn't make much sense. Why would you override USER'S PREFERRED LOCALE just because your website language is something else?

Because all dates in paragraphs and tables will use the Norwegian date format while forms will use the date format of the visitor. Having two date formats on the same page can be very confusing, especially if one is D/M/Y and the other is M/D/Y.

Well, that kinda makes sense. But you really should render the dates also based in user's browser locale.

Our use FEB instead of 02 - this reduces the wondering to zero

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?

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.

> Why must the date format be Norwegian?

Otherwise the page isn't in Norwegian. This is a UX question only.

The form is submitted with ISO 8601 dates, it’s just the UI that localises.

I can see how customizable locale/formatting would be important, but would it really matter if a US visitor to the Norwegian website saw a mm/dd/yyyy date instead of the yyyy-mm-dd that would be shown to those with norwegian locale? The important thing seems to be that the user understands the format. This is client side rendering after all.

It is important that a Norwegian visitor with a browser configured to prefer en-US [1] would see the entire web page in the same locale. Why should _parts_ of the web page localize to a different locale than other parts?

The standard Norwegian date format is DD.MM.YYYY, _easily_ confused with MM/DD/YYYY. Why is it a feature to include this confusion?

[1]: This is pretty common, either deliberately or by accident. If you actually want to serve content localized in multiple ways (eg. you want to serve both an English and a Norwegian version) you have to sidestep browser localization anyway and offer the user a way to select which version they want.

> It is important that a Norwegian visitor with a browser configured to prefer en-US [1] would see the entire web page in the same locale. Why should _parts_ of the web page localize to a different locale than other parts?

Completely agree - that should not happen. Consistency is most important. So if a Norwegian user has an en-US browser and the rendering uses this control which uses default browser locale then all date rendering in all markup has to be en-US. That is: this control can't be used on a web site unless the site already uses browser locale for all date input and output.

If the web page already has custom date formatting (e.g. the user chooses locale/format in the site preferences) or if the page has elements rendererd DD.MM.YYYY already from the back end - then this control can't be used.

(Also: TIL Norway doesn't use ISO 8601 like Sweden. I honestly thought ISO 8601 was norm in Europe, but apparently mostly in Sweden).

According to [1] Sweden uses SS-ISO 8601 and Norway uses NS-ISO 8601.

According to [2]: "All members of CEN[3] (all of Western Europe and Scandinavia, and most of Eastern Europe) are required to adopt the EN 28601 European Standard. Most have now done so"

It's not obvious what this really means though.

[1] https://en.wikipedia.org/wiki/ISO_8601#Related_standards [2] http://www.qsl.net/g1smd/isoimp.htm [3] https://en.wikipedia.org/wiki/European_Committee_for_Standar...

I think [1] only covers how ISO is used in norway. I think if you look at what's actually common you'll find that norwegians use the non-ISO dd.MM.yy most of the time, but when they use ISO they use ISO as in [1] above.

That's the difference to sweden, we'd actually us an ISO 8601 type format as our everyday format.

You're confusing language and locale and that's going to be equally confusing to your users.

I read web content in several languages and expect date formats in ALL applications my application to follow my OS locale which is Finnish.

My Windows operating system is in English, yet my locale is Finnish, so that the date format is Finnish. This is the standard way of using locales. Why would web sites be any different?

This would be terrible for usability. Allow the user to see the date how they want, then you process the data that’s returned.

Yeah I thought that was really confusing! I would have expected that for countries that commonly read left to right and count from small to big the format of day(smallest common date unit)/month/year(largest common date unit) would at least be a sensible default if unable to detect the exact clients country standard, failing that the ISO of YEAR-MONTH-DAY would be fine but not jumbling it up like this and putting the day between the month and year - I know my comment could sound a bit ‘flamey’ but I’m purely interested / invested from the point of view of logical or biology, I don’t care about ‘X country does Y better’.

That would be the case if not the fact US used date format different to everybody else. Is 01/05/2000 1st of May or 5th of January? The answer is: cannot tell without context!

The company I work for settled for the presentation format "23 Oct 2017" for this reason, which is also why we can't use these standard controls :/

Um ... Displaying dates based on locale of client has been the standard for most software for decades. Why call out Firefox for this, now?

Because this is not displaying dates based on the locale of the client, but displaying locale based on the language of the application.

You have to download the en-GB localized browser to get a different date ordering.

Firefox serves localized downloads by default, and you can also manually get the right one (IIRC it lets you override it on the download page)

Grab the en-GB Firefox release? You get dd/mm/yyyy then.

https://www.mozilla.org/en-GB/firefox/all/#en-GB

I have "intl.accept_languages" set to "en-GB,en". "general.useragent.local" is "en-GB". My system preferences are UK English. Yet this new firefox feature gives me the US date format.

That preference only affects the Accept-Language header.

This isn't configurable (yet; I'm trying to make it configurable), but you can download a localized release for en-GB and it should work.

Well it's a cool feature. I'm looking forward to having it configurable. Thanks!

Why is this read off the firefox locale when my system has perfectly decent localization capabilities set up just the way I like it? (US English, 24h, YMD) This seems like another case of the browser becoming an OS within an OS.

For the same reason sites end up implementing language switchers despite your browser having a way to set your preference and send it in an HTTP header.

Huh? How is a localization being tied to a browser bundle vs OS remotely the same as a website offering the ability to view content in different languages?

I can change my OS locale settings just by opening up a panel. Firefox wants me to install a new official locale or a new browser bundle to do the same.

Btw, content language is not a locale preference, it's contextual. Browsers could have a standard dropdown in their UI to change that header on the fly, sure, but that wouldn't make language selection unnecessary. Take something like Wikipedia, the contents are widely different across languages, and switching is common for multilingual readers.

The common reason here is that among people who aren't the sort to post on Hacker News, knowledge of how to change these things -- in the operating system for locale, in the browser for preferred languages -- or even knowledge that these things can be changed, is uncommon.

See also: "you can't fix the user".

Which Chrome seems to think is a setting that every single application needs to control itself, rather than being a system-wide config.

I'm confused, if the operating system is set to use some date format why not use that? You don't need to even reveal the format to Javascript since the input should work without JS.

Language preferences are a totally separate thing, although they could be used as a fallback if date format is somehow not offered by the operating system. E.g. de-CH for a swiss date format, de for a german date format.

Why don't they use the ISO standard for displaying dates? month-day-year makes no freaking sense.

Plus there are no way to distinguish month-day to day-month in a lot of cases

Because you didn't actually read the article.

Only in the sense that people won't be taught to use sane date formats. I don't see any issue with allowing someone who wishes to use the weird format to have their way.

Edit: If you downvote it, be nice enough to let me know what you disagree with.

The downvotes are probably because you seem to miss the point of the parent.

The issue is not about the possibility to have a weird format, the issue is that the format is automatically adjusted to the "weird" one that a lot of people don't like, and that it is not easily configurable.

Obligatory XKCD: https://xkcd.com/1179/

I agree, though. Browsers allow users to customize fonts and zoom levels, so the date formats should probably be a user-configurable setting, too.

The last one is actually the ISO norm. There was of course an xkcd on that subject as well.

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?

According to HTML5 specification this:

    <input type=date lang="pt-BR">

shall work.

Like here: https://sciter.com/temp/date.png

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

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?

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

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?

> 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?

But they already do it for dates in the content of the pages (there is no API for a web server or JS to get the browser UI locale). Why should form elements be different? Imagine how confusing a web site with a D/M/Y dates and a browser with M/D/Y forms would be.

> (there is no API for a web server or JS to get the browser UI locale)

There is: new Date().toLocaleDateString()

Ideally there would be a better way to choose locale on a per-site basis rather than having it be baked into each app individually. Many apps have no settings page, and those that do often require you to log in to change the settings.

I have my browser language set to Dutch but every time I touch Wikipedia or MDN I have to append "english" to my search terms to get a version of the article that isn't strictly inferior.

The reasoning is that this is a brand-new feature that just landed in the Alpha release of the browser and they're just not done yet with every secondary implementation aspect.

Manishearth, who's a Mozilla dev, commented in another thread that he's currently looking into making it configurable.

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.

The best reason for using native form fields (in my experience) is for the mobile devices. Using some old school Jquery custom JS select input means its a very poor experience for mobile. At least on iOS by using native, I get the Safari mobile dates/select inputs that work much better+smoother than js/css alternatives. Of course this doesn't matter if you don't target mobile with your website/webapp.

It’s possible to have both; just make your js component issue a synthetic click on a hidden native input, and read the value when changed. I do this all the time.

And oh the fun you'll have when you try to use a keyboard! (Nope nope nope, everyone clicks, you with the keyboard don't matter, and you with the screenreader just go away already)

The idea is that you are using the native field to listen for user events, so the ux shouldn’t change. You have to proxy click events since the element isn’t visible, but key presses work as usual.

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

Why do you need to be able to control the look of the date picker (or any other input element)?

If every website used the same, it would be much more convenient than the current situation, where each date picker uses a subtly different mechanism to select the individual fields and then confirm the selected date. Most do not even support keyboard input.

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.

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

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

That's why they should have written the controls in Javascript and put it on their CDN, or include it in the browser distribution. Then using the controls would only require a simple include in the head of the document, and you could style the controls just like any other HTML.

No, push back against insane requirements. Why do we want to style input? Bill them for a custom solution if they want a custom solution.

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.

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.

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

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

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.

> 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?

For me entering time by hand is easier then using a mouse and a picker, so it varies.

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

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.

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.

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.

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/

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!

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.

This feature requires that it be a priority at the same time both for the browser UI team and the browser engine team, because of the tight coupling involved to do this right.

There was no point in time before now when this was the case...

Priorities I guess...

I'd say localization.

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

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

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.

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.

> 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?

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.

I know many like me, who also just prefers the application language to be in English. From decades of using English I have no idea what many terms are in my native language, native terms are much harder to google, and many applications are also poorly translated. But that doesn't mean I want everything in English, especially not date/time formats.

Language and locale (how you want your date or numbers formatted) are two different things. You can set them separately.

I can set them, all right. Somebody else then needs to read them, though...and has to take care not to assume that LANG===LC_TIME===LC_DATE. Sadly, I do not see that happening; in most cases, the apps are picking one locale setting, seemingly at random, and using it for all the other locale settings.

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.

Last time I used Peoplesoft it had everything in American date format.

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?

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.

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.

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

That's the reason to use en_GB locale instead. European date and time formats and English language for the UI. Rarely if ever saw anything broken.

Yes I try to do that but I sometimes have used (accidentally) en_US in the past since I use ANSI International keyboard layout but GB locale settings.

Agreed. ISO-8601 is the way to go.

Didn't you know? There does not exist a world outside the US. We're all just illusions and bots.

In the German localization it's correctly displayed as 'dd.mm.yyyy'. Other formats are possible but not yet enabled for every language, it seems.

Weird, given that ´new Intl.DateTimeFormat('fi-FI').format(new Date)´ in console properly outputs dd.mm.yyyy, so the locale data for Finnish should be there.

It uses the locale of your Firefox install (which you can select when you download the browser). This isn't configurable within an install (yet).

I hope the plan is to read the configured date format on the system like most software out there? This really shouldn't need to be manually configured.

Works on Android though (or does the Play Stpre download a localized version for me?).

IIRC it does

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.

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.

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

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.

> I hope it spreads to other browsers quickly.

It is in other browsers for years

Except Safari iirc :(

Or IE11: http://caniuse.com/#feat=input-datetime

TIL you can render HTML from your address bar:

data:text/html, [Your HTML here]

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

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

> What's the benefit of this?

Apart from Xophmeister's point about embedding within a cached resources, two other use-cases:

1. generated or dynamic resources - e.g. displaying an image from a file input before it's uploaded to a server

2. reliability - e.g. Github's 404 page[0] uses them to ensure the entire page source is standalone and works independently of other services/resources.

[0] https://github.com/404

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

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

True; I guess they're then beneficial if the resource is only ever used on that one page.

It's very common to do as part of a compiling/deploying step, for shared files like css or js, very rarely done manually (maybe for very very small icons).

E.g. I use url-loader in webpack to do require('./some_image.png') and that's converted to a data URI if the image is small enough (otherwise I get a regular URI). The output is a .js file shared among all pages of the site.

It means you can do wacky stuff like this: http://www.p01.org/defender_of_the_favicon/

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.

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

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

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

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

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

Ran into similar shock recently while working on a project. Ended up just making my own - was actually fairly straightforward, and pretty fun. Creating 6 <select> menus for date time input would have been obnoxious enough as a developer, but I can't imagine filling that in as a user and not hating the experience. Glad to see Firefox moving in this direction.

Nah, it's been on Mozilla's To-Do list for years already, just realistically not ever really a priority.

And I'm also pretty sure they've already been actively working on the implementation prior to talks with those companies. I think, I remember reading about first design steps at the start of the year already.

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.

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

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.

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

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.

> 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".

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.

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?

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.

Ok, but you can already do that.

Or do you want to enforce it somehow?

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

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

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.

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

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.

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

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"!

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.

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?

Modernizr detects supported input types: https://github.com/Modernizr/Modernizr/blob/master/feature-d...

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.

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

For <input type="date">, it's a https://html.spec.whatwg.org/multipage/common-microsyntaxes.... (see <https://html.spec.whatwg.org/multipage/input.html#date-state... though you have to know how the inputs section of the spec works in general to see that it enforces the "valid date string" constraint). To translate from spec to something readable, it's YYYY-MM-DD, with nothing else.

For <input type="time"> it's <https://html.spec.whatwg.org/multipage/common-microsyntaxes..... Again, to translate to something readable, it's HH:MM[:SS] where the :SS part is optional if seconds is 0, and all numbers are 0-based (so 0 <= HH <= 23, 0 <= MM,SS <= 59).

For <input type="datetime-local"> it's https://html.spec.whatwg.org/multipage/common-microsyntaxes.... which is yyyy-mm-ddThh:mm[:ss] without any timezone information, afaict, and with [:ss] guaranteed to be left out if 0.

ISO 8601 (yyyy-mm-dd)

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

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.

> 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

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

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

It used to be just a regular text input, from now on it should have a datepicker. Just like all other latest versions of major browsers apart from (desktop) Safari.

No week picker? Edge and Chrome implement it.

finally not only in chrome (and apparently opera)

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

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.

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.

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.

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

This is not newsworthy.

But will the inputs be mixed-reality ready?

Reply on news.ycombinator.com