[WOOMOB-3725] Follow the locale's date order in analytics date ranges

[irfano]

Fixes WOOMOB-3725

Analytics date ranges were built by formatting the two dates separately and joining them, with the second one shortened when both fell in the same month. That shortening only reads correctly when the month comes first, so the whole range was pinned to the American order: British English showed Aug 3 – 9, 2026 where the language calls for 3 – 9 Aug 2026.

Description

formatAsRangeWith now hands both dates to ICU's DateIntervalFormat with a yMMMd skeleton. Which part is shortened, where the year lands and which separator is used are all decided per language, so ranges match the single dates fixed in WOOMOB-3262.

The AI assistant stats card composed its period the same way and moved over too.

The two date comparison helpers the old composition needed are gone, they had no other callers.

formatAsRangeWith has no dedicated test: it is a single line handing the two dates to ICU, with no logic of its own to cover. Unit tests stub the interval formatter with a plain full-date join, deliberately not copying ICU's elision, so test expectations pin our wiring rather than ICU's output. The range description tests in StatsTimeRangeSelectionTest are removed with the hand-rolled composition they asserted; the date information tests in the same file keep covering the range boundary math.

American English analytics ranges are unchanged: ICU produces the same string the old code did for every same-month, same-year and cross-year case, so the existing assertions still pass untouched. The AI assistant card is the one exception: it used to repeat the month within the same month, so May 1 – May 7, 2026 now reads May 1 – 7, 2026, same as the analytics screen.

Test Steps

Analytics

1. Set the app language to English (United Kingdom) from the system settings.
2. Open My store.
3. Tap View all store analytics.
4. Confirm the range reads 3 – 9 Aug 2026 for Last Week, not Aug 3 – 9, 2026.
5. Confirm the comparison line reads 27 Jul – 2 Aug 2026.
6. Tap the range selector.
7. Tap Last Year.
8. Confirm the range reads 1 Jan – 31 Dec 2025.
9. Tap the range selector.
10. Tap Month to Date.
11. Confirm the range starts with the day.
12. Switch the app language to English (United States).
13. Repeat steps 2 to 4 and confirm the range reads Aug 3 – 9, 2026.

AI assistant

1. Set the app language to English (United Kingdom) from the system settings.
2. Open the AI assistant.
3. Ask for this week's revenue.
4. Confirm the period above the metrics on the analytics card starts with the day.

Images/gif

Emulator with the app language set to English (United Kingdom).

	Before	After
Analytics, last week
Analytics, last year
AI assistant stats card

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Build Number	778
	Version	25.4-rc-1
	Application ID	com.woocommerce.android.prealpha
	Commit	b899151
	Installation URL	5rjksl1lcl570

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[claude]

AI Code Review - Found 1 potential issue

[follow-up] StatsTimeRangeSelectionTest drops the ~11 tests that asserted currentRangeDescription/previousRangeDescription for the year-to-date, last-year, quarter, month, week and custom selection types, leaving no coverage of the new formatAsRangeWith description wiring. The range boundaries are still covered by the retained currentRange/previousRange assertions, and LocalizedDatePatternsTestRule now stubs the ICU APIs, so a representative description test could be restored to guard against formatting regressions. Deferring is defensible since the formatting itself is delegated to ICU.

The rest of the change looks correct: minSdk is 26 so the android.icu DateIntervalFormat/DateInterval APIs are safe to call; the by lazy conversions in the tests correctly defer range-selection construction until after the rule has stubbed the ICU statics (property initializers would otherwise run before @Rule.starting); and the single-day (formatToLocalizedMonthDayYear) vs. multi-day (formatAsRangeWith) paths stay stylistically consistent.

PR housekeeping

• Applied repo AGENTS.md/CLAUDE.md guidance (Kotlin, store-app conventions) while reviewing.
• Testing: user-facing change is analytics/AI-assistant date-range wording; the updated unit tests assert the new formatted strings via LocalizedDatePatternsTestRule.

---

_{Automatic review · claude-opus-4-8 · Workflow run}

_{How to reply to a finding}

Reply on this review (or inline at the line the finding refers to) with one of:

• @claude addressed - I made the change. Bot verifies against the next diff before marking resolved.
• @claude rejected: <reason> - Will not fix; reason gets quoted on the next review.
• @claude not-applicable - Finding does not apply (wrong file, already covered elsewhere, etc.).

The bot honours these on the next review pass.

[irfano]

AI Code Review - Found 1 potential issue

[follow-up] StatsTimeRangeSelectionTest drops the ~11 tests that asserted currentRangeDescription/previousRangeDescription for the year-to-date, last-year, quarter, month, week and custom selection types, leaving no coverage of the new formatAsRangeWith description wiring. The range boundaries are still covered by the retained currentRange/previousRange assertions, and LocalizedDatePatternsTestRule now stubs the ICU APIs, so a representative description test could be restored to guard against formatting regressions. Deferring is defensible since the formatting itself is delegated to ICU.

The rest of the change looks correct: minSdk is 26 so the android.icu DateIntervalFormat/DateInterval APIs are safe to call; the by lazy conversions in the tests correctly defer range-selection construction until after the rule has stubbed the ICU statics (property initializers would otherwise run before @Rule.starting); and the single-day (formatToLocalizedMonthDayYear) vs. multi-day (formatAsRangeWith) paths stay stylistically consistent.

PR housekeeping

• Applied repo AGENTS.md/CLAUDE.md guidance (Kotlin, store-app conventions) while reviewing.
• Testing: user-facing change is analytics/AI-assistant date-range wording; the updated unit tests assert the new formatted strings via LocalizedDatePatternsTestRule.

Automatic review · claude-opus-4-8 · Workflow run

How to reply to a finding
Reply on this review (or inline at the line the finding refers to) with one of:

• @claude addressed - I made the change. Bot verifies against the next diff before marking resolved.
• @claude rejected: <reason> - Will not fix; reason gets quoted on the next review.
• @claude not-applicable - Finding does not apply (wrong file, already covered elsewhere, etc.).

The bot honours these on the next review pass.

@claude rejected: The rule stubs ICU in unit tests, so a restored description test would assert the stub's output, not the formatting. The composition those tests covered moved into ICU, formatAsRangeWith only forwards the two dates and has nothing of its own left to test.