We had a discussion in the CLDR meeting 9/30 about how DateTimePatternGenerator should handle matching of number of hour digits to satisfy 2 different types of requests, namely:
Give me the locale's default number of hour digits
2. Give me the number hour digits specified by the skeleton, in order to match a user format customization
The solution was:
should be the default behavior.
can be obtained by an API option that forces the returned pattern to have the same number of hour digits as the skeleton.
To implement this:
We need to make sure that DateTimePatternGenerator code that matches returned pattern field length to skeleton field length is turned off for hour fields (h, H, k, K).
We need to add an API option to override this.
This is urgent in order to make sure that examples generated in the CLDR survey tool are correct.
This bug will cover the C changes. The J changes are already covered by a general bug to update the DateTimePatternGenerator J code to sync with C, ticket #6872.
Note that currently the DateTimePatternGenerator C implementation is such that if there is a skeleton that has the desired field length, the pattern field will not be changed to match the request. So a locale default of (say) two digits can be obtained by providing multiple entries, such as
skeleton -> pattern
This is done in several locales. The solution in this bug's proposal would permit replacing those multiple entries by a single entry.
An e-mail was sent to icu-design on Nov 16, 2009 (PT): "DateTimePatternGenerator option to force digit length match". There was subsequent discussion at the ICU meeting of 2009/12/2. The decision on how to add an API option (to allow forcing of the number of digits in the returned pattern to match those in the skeleton) was, for C++:
We will do something similar in C.
Milestone 4.3.4 deleted