Switching language should update date and time formats

[SergeyBiryukov]

Previously: #11226

1. Install WordPress in English.
2. Switch language to Russian.
3. Date and time formats in General Settings are still F j, Y and g:i a, which doesn't make sense for Russian and doesn't match the locale defaults (d.m.Y and H:i, respectively).

[Clorith]

This would need to account for those who have set their own date and time formats though, so as not to override user settings that may differ from what we expect from a locale.

[swissspidy]

This would need to account for those who have set their own date and time formats though, so as not to override user settings that may differ from what we expect from a locale.

It could work by not saving the date and time formats to the database until they differ from the ones specified by the locale.

[vagios]

In 36259.patch, if the locale's default date/time format is used, after the update the new locale's default values will be used. In any other case the code works as before.

[DrewAPicture]

Related-ish: #28344

[only1andrewh]

Replying to vagios:

In 36259.patch, if the locale's default date/time format is used, after the update the new locale's default values will be used. In any other case the code works as before.

I just tested this patch, and if left on the default time format it changes to the one specific to the chosen country.
Before applying the patch I confirmed that the old local was going into the custom format and active.

[DrewAPicture]

Assigning ownership to mark the good-first-bug as "claimed".

[pento]

Patch needs a refresh, testing, and review.

[ocean90]

#54923 was marked as a duplicate.

[sarumbear]

It is all good to mark https://core.trac.wordpress.org/ticket/54923 as duplicate but this is a six year old bug, which still has no defined milestone. How can we attract attention to it?

I find it strange that a bug that allowed a general setting, which has a dedicated page, to fail for six years. (I assume the code is the same between .com and .org.)

​https://wordpress.com/support/language-settings/

[seepops]

I agree with @sarumbear this seems to be forgotten about. I have custom post types that use the published date and it is confusing and irritating not being able to change the dates in the admin to UK format i.e. dd/mm/yyyy. Please get this looked at.

[jornp]

Screenshot (before, English, default format selected)

[jornp]

Screenshot (after switching to Dutch, the default Dutch formats are selected)

[jornp]

I've updated the patch to work with the current WordPress version. Also, in the original patch, the update_option calls were performed before the translations of the new locale were loaded. I've moved the calls to be performed right after the switch is made.

This patch seems to be working correctly, see the screenshots above. I think this could use some unit tests moving forward.

Trac ticket: #36259

Patch used: https://core.trac.wordpress.org/attachment/ticket/36259/36259.diff

## Description:

Added a unit test that verifies date and time formats are updated when switching locale.

## Testing Instruction:
Run following command to verify the test:

npm run test:php -- --filter=Tests_I18n_SwitchingLocaleUpdatesDateTimeFormats

[SirLouen]

Test Report

Description

🟠 This report validates that the indicated patch works as expected with some caveats regarding Unit Testing.

Patch tested: REPLACE_WITH_PATCH_URL

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 135.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0
  • WP_Query Tester 1.0.0

Bug Reproduction

1. Go to General Settings
2. Set to any language different from English with different time locales
3. 🐞 Bug Occurs

Expected Results

• The time locales should adapt to the Language

Actual Results

• ✅ Issue resolved with patch. I've tested with Russian and Spanish and everything changes accordingly
• ❌ Unit tests are useless (check Additional Notes)

Additional Notes

1. Despite Unit tests are passing accordingly, passing test without patch don't break them
2. There is another file more adequate to "Internationalization Locale Switches" in this path: tests/phpunit/tests/l10n/wpLocaleSwitcher.php

[fishtron]

I tried updating the unit test and discovered a couple of things:

1) The patch might have some unintended consequences. Since it checks for the user locale, the dashboard is changing the default date/time format based on the user's locale rather than the site's default locale. This might not be what's intended and/or might not be what the user expects.

2) The code for changing options is not unit-testable because it is written procedurally in the options filter. Currently it can only be tested with end-to-end testing, unless the admin options functionality is rewritten.

(With help from @pbearne and @desrosj at WCEH 2025 Contributor Day!)

[desrosj]

In chatting this through with @fishtron and @pbearne, @swissspidy's suggestion above to not save a value to the database for the two options unless a non-default one is entered/selected seemed like the best approach at first.

However, it seems that this will cause problems within plugins and themes as using get_option() to ​retrieve these two values directly is quite common (acknowledging that this site is not up to date with the current state of the directory for several months).

Here are some additional observations:

• When the F j, Y format is not the default for the active locale, the form renders with \c\u\s\t\o\m as the selected radio button and F j, Y (which is a pretty common and standard date format) is not available as an option.
• It may be nice to include something to the effect of "(language default)" next to the top option to make it clear that format is the default.

[pbearne]

@desrosj

Made start on adding language default text https://core.trac.wordpress.org/ticket/64102