udat_formatForFields reports same field position as "a" and "B"


In the following example, the field position [3, 4] is reported as "a" and "B", but only a single field format kind is expected.

This issue affects the ECMA-402 PR <https://github.com/tc39/ecma402/pull/346>.


Test case:


Shane Carr
December 10, 2019, 7:29 AM

Thanks for the investigation!

Does this bug happen whenever `subFormat` calls another `subFormat`? I see 3 places where `subFormat` recurses like that.

Maybe we should `return` instead of `break` after recursing to subFormat?

Caio Lima
December 10, 2019, 5:46 AM

FYI, this bug is also reproducible if we use field b.

Caio Lima
December 10, 2019, 5:45 AM

After inspecting the code, I found why we have 2 attributes reported for the same field position. On SimpleDateFormat::subFormat when handling case UDAT_FLEXIBLE_DAY_PERIOD_FIELD ( ), we fallback to subFormat(appendTo, 'a',…) when there is no Day Period Rule Set or if given day period is not present on the locale. However, handler.addAttribute is still executed after subFormat(appendTo, 'a',…) returns, duplicating field position. The fix seems to be straight forward once we decide which field we should place when the locale doesn’t support flexible day period. I’m not sure if for a given locale we should return a or B.

André Bargull
October 21, 2019, 6:41 AM

Maybe the problem just ceased to exist in `en-001` due to some CLDR data changes for that locale? But the overall problem of reporting the same field position twice is still present and can be reproduce with a wide range of locales.

To reproduce change the example code to iterate over all locales:



And then remove any `u_printf` and printfcalls. And finally change the `ufieldpositer_next loop to:



That should produce a list of 305 locales for which the bug is still reproducible.

Shane Carr
October 16, 2019, 10:51 PM

As Caio found on the PR, this is reproducible in ICU 64 but is no longer reproducible in ICU 65.



Caio Lima


André Bargull





Fix versions