@Samwilson @Mooeypoo @MusikAnimal @MaxSem @aezell This ticket will be estimated in our Tuesday meeting. Let's discuss any potential concerns/missing information on the ticket ahead of that meeting.

It should be localized to whatever you have set on your computer/browser (FormatExtension::dateFormat).

@MusikAnimal When you say "should" do you mean that it works that way now or that we need to change it to work that way?

Works that way now, but it might be going off of locale and not specific date format settings. In MacOS it seems you can't force ISO 8601.

@MusikAnimal Huh, I didn't know I could customize the date format in my Mac!! I could have used it all these years instead of grumbling how people make dates unreadable all over the web. :/
I suppose there is no way to know if someone has intentionally set their date format a certain way rather than it being the default their OS was shipped with.

I'd say we should switch it to be consistent. @Shouston_WMF do you have thoughts on this ticket?

In T201704#4495098, @MusikAnimal wrote:

Works that way now, but it might be going off of locale and not specific date format settings. In MacOS it seems you can't force ISO 8601.

That seems to be correct actually. I changed my local settings but the format in the UI didn't change. I hard-refreshed a few times and went incognito for good measure.

Yeah, going by language is still generally accurate for what is the norm -- e.g. en-US (m/d/y) vs en-GB (d/m/y). But if it's confusing we can certainly force ISO 8601. It's just a matter of using a different method. Note that the datepicker when creating an event will need to be updated as well.

The default locale is en (in config.yml), so why is the date being formatted according to en-US?

Although, maybe there's something else going on: it seems that changing that setting has no effect (at least, on my local installation). Maybe it's being ignored by the Twig function somehow?

My guess is your browser/computer locale is overriding it. If I change the language to Deutsch, I see the D.M.Y format. It's using IntlDateFormatter, so whatever PHP thinks is best.

I do something similar for Pageviews Analysis (except using JavaScript) and the reception is mixed. At the beginning I was using ISO 8601 but some people begged for it be in their local format. Now it is localized by default, with an option to use ISO 8601. Some people appreciate this, others are confused and didn't realize their browser wasn't set to their preferred locale, others leave snarky feedback linking to https://xkcd.com/1179/ :)

I'd prefer we default to showing ISO 8601 format but I'd seek @jmatazzoni's and @Shouston_WMF's opinion on this.

In T201704#4502859, @Niharika wrote:

I'd prefer we default to showing ISO 8601 format but I'd seek @jmatazzoni's and @Shouston_WMF's opinion on this.

If I understand correctly, the system currently mimics the user's preferred date format. That works fine for me, and I might suggest leaving this as is to see if anyone complains. (We could always add an "i" info icon to explain that the date is in your preferred format of your OS).

Net-net, it seems likely that any change we make will make as many people happy as unhappy, right? But if @Niharika thinks the format should be internationalized that is fine with me as well.

It's not quite the user's preferred date format, it's the server-side locale's date format, and for the en locale it uses m/d/y dates (can anyone explain why this is? is en a shortcut for en-US somehow?). If the user switches to British English the dates change correctly. I quite like @aezell 's idea above of rendering dates on the front-end to use the browser's preferred date format, but that's lots more work.

There's no way to switch to e.g. Canadian English because there's no translations for that (adding an empty i18n/en-ca.json file fixes this; is that okay to do?). The standard date format in the en-ca locale is y-m-d by the way. :)

Can't add Australian English though! :( I've created https://github.com/Krinkle/intuition/pull/87 to fix this.

Intuition gets its language list from MediaWiki, so the en-au change is actually https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/452879/

In T201704#4504038, @Samwilson wrote:

Intuition gets its language list from MediaWiki, so the en-au change is actually https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/452879/

Wow, that's a complex process for a task this small. :/

@jmatazzoni As Sam explains, it's not quite the user's preferred format.

Given that, I'd prefer to switch to ISO 8601 everywhere. At least it's consistent and readable for everyone even if it might not be what the user exactly desires.

Good plan.

(As far as adding things to Intuition goes, I've also opened https://github.com/Krinkle/intuition/pull/89 for not having to go through the MediaWiki rigmarole.)

PR: https://github.com/wikimedia/grantmetrics/pull/114

The datepicker will be done as a separate patch (see my comments on the above PR for why).

There's also the question of what order the languages should be listed in (not that that's particularly part of this patch, but it's related). At the moment they're alphabetical by native name, which puts Canadian English and English a bit apart. We could re-order by ICU language code, which would sort by language code, script, and then country.

We should explore using the data part of ULS for this, or, alternatively, at least as a first step, use ULS itself.

While its design may be rigid for us to change, the features ULS provides are pretty powerful out-of-the-box, including language selection by search in multiple languages, and displaying of what should be the user's "most likely" languages in the first window (calculated from OS and browser available languages)

I've added a task to examine this option here: T203699: GrantMetrics: Consider using ULS for language selection

Merged date-formatting patch, and updated staging site. See what you think (note that you can change to 'US English' to get the old date format back).

It doesn't seem like ULS provides date formats (or other non-language locale stuff). Is that correct? Because we still need to fix the datepicker's format. But the main issue described in this ticket is maybe sorted.

I inadvertently deployed this along with T201437 and T200541. The deploy script just pulls from master, so this code went with it. If there are any concerns, let us know and we'll get a fix out ASAP! Gonna leave this in the Product/QA column for now.