Fix #1243: getShortWeekdays() now uses English keys after localization#5105
Merged
Merged
Conversation
…days (#1243) DateFormatSymbols.getShortWeekdays() passed the already-localized getWeekdays() array to createShortforms(), so the resource-bundle lookup used keys derived from the localized long name (e.g. WEEKDAY_SHORTNAME_MAANDAG) instead of the documented English key WEEKDAY_SHORTNAME_MONDAY. With a Dutch bundle containing WEEKDAY_LONGNAME_MONDAY=maandag and WEEKDAY_SHORTNAME_MONDAY=ma, getShortWeekdays() returned "maa" (the first three characters of the long name) instead of "ma". Switch to the English WEEKDAYS array, mirroring how getShortMonths() already handles months. This makes the WEEKDAY_SHORTNAME_<EnglishDay> keys actually resolve, and aligns the no-bundle fallback ("Mon", "Tue", ...) with the no-bundle fallback for months. Fixed in all three DateFormatSymbols copies — the user-facing com.codename1.l10n one and the JDK-API-compatible copies under Ports/CLDC11 and vm/JavaAPI — so behaviour is consistent across the core framework, the J2ME-style port and the ParparVM Java API. Adds maven/core-unittests/.../DateFormatSymbolsTest.java covering the localized-key, localized-long-name, and no-short-key fallback paths. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
Cloudflare Preview
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 47 screenshots: 47 matched. |
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Contributor
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
This was referenced May 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DateFormatSymbols.getShortWeekdays()was looking up resource-bundle keys by the localized long name instead of by the documented English-key constant. With a Dutch bundle ofWEEKDAY_LONGNAME_MONDAY=maandag+WEEKDAY_SHORTNAME_MONDAY=ma,getShortWeekdays()returned"maa"(the first three characters of the long name) instead of"ma".com.codename1.l10n.DateFormatSymbols: pass the EnglishWEEKDAYSarray tocreateShortforms— exactly the waygetShortMonths()already passesMONTHS. The reporter pinpointed this fix in the original issue body.Ports/CLDC11/src/java/text/DateFormatSymbols.javaandvm/JavaAPI/src/java/text/DateFormatSymbols.javaso behaviour is consistent across the core framework, the J2ME-style port and the ParparVM Java API.maven/core-unittests/.../DateFormatSymbolsTest.javawith three cases:getShortWeekdaysUsesEnglishKeyAfterLocalization— the original 2014 repro from getShortWeekdays() in DateFormatSymbols localize the localized 'long week names' #1243. Fails on master withexpected: <ma> but was: <maa>.getWeekdaysReturnsLocalizedLongNames— sanity check that the long-name path is untouched.getShortWeekdaysFallsBackToEnglishPrefixWhenShortKeyMissing— the no-shortname-key fallback now returns"Mon"(the English prefix) instead of"maa"(the localized prefix), matching whatgetShortMonths()has always done for months.Test plan
mvn -pl core-unittests -Dtest=DateFormatSymbolsTest test— 3/3 pass after the fix; before the fix, 2/3 failed with the exact symptoms the 2014 reporter described.mvn -pl core-unittests -Dtest='SimpleDateFormatTest,DateFormatPatternsTest,SimpleDateFormatTestTest,DateFormatTest2772PortTest,DateFormatSymbolsTest' test— all 17 date-related tests still green, no regressions.Behaviour change for consumers without a resource bundle
When no resource bundle is set,
getShortWeekdays()now returns["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"](the prefix of the English long name). This matches the existinggetShortMonths()behaviour and the JDK's own US-English defaults. It is the same string that the buggy code already produced for an English bundle, so apps relying on the English defaults are unaffected. Apps that have been observing the old buggy behaviour for a non-English bundle (truncated localized long names) will now correctly resolve theirWEEKDAY_SHORTNAME_*keys.🤖 Generated with Claude Code