Hacker News Reader

Comment by snitko | Hacker News Reader

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.

View on HN

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.

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

Assuming that is anyone left that cares about it.

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.

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

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.

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

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.

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.

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?

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?

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

> Why must the date format be Norwegian?

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

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.

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

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

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

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.

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

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.