A. There is a major problem in that the ICU data file generated from CLDR has bogus "from" values.
Source in CLDR
Result in ICU
When you list out the ICU info, you see that it is:
However, the from= field is defined to have the value -∞ (FFFFFFFFFFFFFFFFL) if missing, and the to= field is defined to be +∞ (7FFFFFFFFFFFFFFFL) if missing. That is not working for the from= field: we are getting some completely bogus from= value, which shows up in the API. The following code generates the above.
To fix this, we need to drop the default from: value in ldml2icu_supplemental.txt (currently line 17).
; /CurrencyMap/$1/<FIFO>/from:intvector ; values=9999-12-31
That will then result in the correct output for ICU, the somewhat smaller:
That will work correctly with the ICU4J code below
We need to check the ICU4C code to make sure it works too. And add tests to both that CHW has a from value of FFFFFFFFFFFFFFFFL.
B. Both the from and to values are being interpreted in CLDR as local time, while they are interpreted in ICU as GMT!
To fix this, in SupplementalMapper, interpret the date formats in local time, using the default timezone for the region.
C. ICU currently has the following ugly code. That forces a parse every time the currency information is accessed. It should be fixed to:
a. Make sure that the CLDR data is clean: add a test that every date is complete, and of the form yyyy-MM-dd.
If there is no month, add -01 for from=, and -12 for to=
If there is no day, add -01 for from=, and end of the month if to=
b. Do the endOfDay fix in the SupplementalMapper instead of in ICU code. That is, the code needs to distinguish to: from from:, and in the to: case add 23:59:59.999 millis.
c. Change the ICU code to not do any of the following funky parsing.
A and C fixed in this ticket, B moved to .
Milestone 23dres deleted