Some date formats get incorrectly output in Italian

[Clorith]

When using the date format l j F Y (Monday 11 November 2019), and changing the site language to Italian, the output becomes "Lundeì 11 20 Novembre 19", essentially embracing the month with the year.

This output shows up in the preview in wp-admin when changing the format, and in the front end, for example the date display in Twenty Twenty above posts.

The behavior changed with the 5.3 release, and I've so far only had reports and replicated this with Italian, but there may be other strange scenarios with other languages.

[Rarst]

I think this got broken by additions in wp_maybe_decline_date(), [45555]

There was unit test added for Russian with it, so the issue might be it not behaving right with another locale(s).

I didn't write the code, will look into it on fresh head.

[Rarst]

Yeah, it's broken in Russian as well.

So we start with "Thursday 14 November 2019" (I'll do this in English for clarity) and have two steps in the logic here:

1. First we have quick check for non-digits followed by 1-2 digits and optionally ordinal suffix (e.g. Foo 1st, Bar 22nd). In this case this is actually matching "Thursday 14" while we were kinda looking for the month, not day of the week.
2. We are trying to replace any name of the month, followed by same 1-2 digits + optional suffix by those digits, followed by genitive name of the month. But! Here name of the month followed by 1-2 digits is actually (November 20)19, which replacements turns into '20 November19'

Possible fixes:

1. Replace if followed by 1-2 digits, but no more digits than that. This would still be wrong if year happens to be represented by 2 digits.
2. Make ordinal suffix mandatory for replacement and leave it alone otherwise.

Pinging @SergeyBiryukov who wrote original patch for opinion.

[Rarst]

I've added a patch to make ordinal suffix mandatory for replacement and fix outstanding visual error.

In long term we probably need to scrap the whole implementation and write it from scratch. The current one doesn't have access to actual format used and just a pile of wildly guessing regex. I'll make a new ticket for rewrite once we patch specific regression here.

[nielslange]

#48690 was marked as a duplicate.

[SergeyBiryukov]

#48741 was marked as a duplicate.

[robydc]

Replying to Rarst:

I've added a patch to make ordinal suffix mandatory for replacement and fix outstanding visual error.

In long term we probably need to scrap the whole implementation and write it from scratch. The current one doesn't have access to actual format used and just a pile of wildly guessing regex. I'll make a new ticket for rewrite once we patch specific regression here.

Excuse me, how can I use that patch? I have the same error date display in italian language, what shall i do with that patch?
Thank you.

[Rarst]

Excuse me, how can I use that patch? I have the same error date display in italian language, what shall i do with that patch?

This is planned to be included in WordPress version 5.3.1 so everyone will get the fix when it's released.

If you need the fix more urgently you can temporarily switch to a different date format (where month isn't followed by a year) or apply the patch to your copy of core (not generally recommended).

[SergeyBiryukov]

In 46862:

Date/Time: When determining whether to decline the month name in wp_maybe_decline_date(), take word boundaries into account.

Add more unit tests.

Props Rarst, Clorith, timon33, Xendo, SergeyBiryukov.
Fixes #48606.

[SergeyBiryukov]

In 46863:

Date/Time: When determining whether to decline the month name in wp_maybe_decline_date(), take word boundaries into account.

Add more unit tests.

Props Rarst, Clorith, timon33, Xendo, SergeyBiryukov.
Merges [46862] to the 5.3 branch.
Fixes #48606.

[Rarst]

I am not sure this is sufficient solution long term, since underlying ambiguity is not resolved.

For example Январь 19 ("January 19" in Russian) is assumed to be 19th day of January and declined, while it might be 19th year (as in 2019) and shouldn't be.

It is impossible to distinguish meaning of arbitrary digits and string, without knowing underlying format or having them disambiguated by ordinal suffix.

[SergeyBiryukov]

Replying to Rarst:

I am not sure this is sufficient solution long term, since underlying ambiguity is not resolved.

Yes, I agree it's not a comprehensive solution :)

FWIW, ​Italian doesn't seem to decline month names, so turning on the ​setting for that language appears to be a translator's mistake.

[46862] is just an attempt to address the regression without introducing new regressions in languages that do use month declensions, which would somewhat defeat the purpose of the function.

For example Январь 19 ("January 19" in Russian) is assumed to be 19th day of January and declined, while it might be 19th year (as in 2019) and shouldn't be.

Right, however the latter is far less common from my experience, I'd call that an acceptable edge case for now.

It is impossible to distinguish meaning of arbitrary digits in a string, without knowing underlying format or having them disambiguated by ordinal suffix.

Indeed, I'm open to rewriting the current implementation from scratch in a future release, as you've suggested in comment:4.