Localization issue: US date format is confusing to everyone

[da2x]

“Next contribution: ⁨10/4/2016⁩.”

So I have to wait until April 10th? Wait, that is five months ago … .

Practically speaking everyone in the world uses a little-endian date format with day, month, followed by the year whereas the middle-endian [madness] is limited to the US.

To avoid any confusion and avoid the cost of actually having to localize it to every region, please choose one of the below formats:

• October 4th 2016 (full date, would still require translation and localization)
• 2016-10-04 (big-endian international standard date format, no localization required)
• In X days (countdown to date, two–five strings to translate per additional language)

[luixxiul]

In Japanese it would be 2016年4月10日, for example.

[jonathansampson]

I'd case my vote for the last (X days…), and possibly with a title that shows the October 4th 2016 date.

[bsclifton]

this should be a super easy fix- just using toLocaleDateString

History page also uses this- perhaps it can be pulled out to a helper class, like formatUtil.js?

[cezaraugusto]

Agreed that this is confusing (I also read April, 10th). I'm with @jonathansampson with countdown to date.

/cc @bradleyrichter what do you think?

[bradleyrichter]

This USA difference is confusing but we have many US customers.

So countdown in days is probably best.

"Next contribution in 11 days."

This also solves a deeper problem where we need to update the date because you were on vacation during the initial reported date. (closed computer)

So in this case, when you start up again, it will just say "in 11 days".

@bsclifton I think the format in about:history is fine as is given the above choices suggested by @Aeyoun. (and thanks for the detailed issue!)

[bradleyrichter]

@ayumi acceptable quick fix if countdown requires too much work:

2016-09-28 (big-endian international standard date format, no localization required)

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

[ayumi]

@bradleyrichter thanks, I do generally enjoy that date format

[bsclifton]

I like the countdown 😄 But if we don't use countdown, is there a reason we wouldn't want to show the date in the user's locale format? (ex: using https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString)?

As long as we're updating the locale when user changes it using preferences and processing it correctly, we'll get the formatting 100% for free since it's a standard JS function

[da2x]

is there a reason we wouldn't want to show the date in the user's locale format?

Many users have incorrectly configured computers and don’t know how to change it. (At least here in Europe. When I buy hardware here in Norway, I often get Finish, French, or British locale by default and can change to Norwegian in Settings.) Devices are often localized to not only one market but many markets get the same pre-configured setup with a small instruction brief on how to configure it .

You also have the problem of the German living in Spain doing business with Americans and FaceTimeing with his Chinese partner…. No one really know what date format that person excepts their computer to show them at any given time.

Dates are hard. 😄 ISO date is supposed to be the solution! It has been recommended by W3C for use on the web ever since 2002 and they use it in all spec recommendations. All commerce and finance in EEA/EU is supposed to use ISO-8601. (Something about lowering barriers to trade and stuff.)

Disclaimer: I really like ISO 8601 so I may be biased.

[bsclifton]

@Aeyoun thanks for the explanation- I think it's a great compromise 😄