-
Bug
-
Resolution: Fixed
-
P4
-
20
-
b10
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8299471 | 17.0.7-oracle | Ramesh Gangadhar | P4 | Resolved | Fixed | b01 |
| JDK-8301707 | 17.0.7 | Goetz Lindenmaier | P4 | Resolved | Fixed | b01 |
spotted on my dev (Windows) machine; the test fails with:
testFormatting. Pattern: yyyy-MM-dd HH:mm:ss.SSS v, expected: 2019-12-06 22:06:12.372 Custom Time, formatted: 2019-12-06 22:06:12.372 Custom/Timezone
CustomTimeZoneNameProvider#getAvailableLocales uses Locale.getDefault() which returns en_US. DateTimeFormatterBuilder#toFormatter uses Locale.getDefault(Locale.Category.FORMAT) which returns pl_PL.
testFormatting. Pattern: yyyy-MM-dd HH:mm:ss.SSS v, expected: 2019-12-06 22:06:12.372 Custom Time, formatted: 2019-12-06 22:06:12.372 Custom/Timezone
CustomTimeZoneNameProvider#getAvailableLocales uses Locale.getDefault() which returns en_US. DateTimeFormatterBuilder#toFormatter uses Locale.getDefault(Locale.Category.FORMAT) which returns pl_PL.
- backported by
-
JDK-8299471 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if defaultLocale and defaultFormatLocale are different
-
- Resolved
-
-
-
- Resolved
-
- links to
-
Commit
openjdk/jdk17u-dev/50c34336
-
Commit
openjdk/jdk/4772354f
-
Review
openjdk/jdk17u-dev/1135
-
Review
openjdk/jdk/9729
(1 links to)