Vers. 3.3 Datum Eingabe in Liste nicht möglich

[lundefugl]

Ich habe noch etwas geforscht und auch den RC-Code verglichen.

Im RouteConverter wird neu jetzt die im RouteConverter eingestellte Locale als Basis für die Bestimmung des Patterns benutzt und nicht die Locale, die Java beim Start automatisch bestimmt hat.
Und hier kommt bei einigen Locales irgendwie Blödsinn beim Format zurück. Ein einzelnes y ist nach CLDR nicht zulässig. Der Parser bei Java liest dann einfach alles bis zum Ende des Strings als Jahreszahl. So lange das y am Ende steht, ist das auch "kein" Problem. Es wird nur ein Problem, wenn es nicht am Ende ist.

Folglich bei folgenden fett markierten Sprachen:
ar_SA --> "d‏/M‏/y"
pt_BR --> "dd/MM/y"
ca_ES --> "d/M/yy"
zh_CN --> "y/M/d"
cs_CZ --> "dd.MM.yy"
da_DK --> "dd.MM.y"
de_DE --> "dd.MM.yy"
en_US --> "M/d/yy"
es_ES --> "d/M/yy"
fr_FR --> "dd/MM/y"
hr_HR --> "dd. MM. y."
it_IT --> "dd/MM/yy"
ja_JP --> "y/MM/dd"
ko_KR --> "yy. M. d."
lv --> "dd.MM.yy"
hu_HU --> "y. MM. dd."
nl_NL --> "dd-MM-y"
nb_NO --> "dd.MM.y"
pl_PL --> "d.MM.y"
pt_PT --> "dd/MM/yy"
ru_RU --> "dd.MM.y"
sk_SK --> "d. M. y"
fi_FI --> "d.M.y"
sr_SR --> "d. M. y."
ta --> "d/M/yy"
tr_TR --> "d.MM.y"
uk_UA --> "dd.MM.yy"
ROOT --> "y-MM-dd"

@Christian: Ich denke, dass die Ursache ist, dass die Locale von Hand aus Language & Country zusammengebaut wird. Und sobald es diese Kombination bei Java nicht gibt, kommt da was komisches zurück.
Vermutlich stimmen auch andere Locales nicht ganz, wenn das y am Ende allein steht.

Ich werde da noch etwas forschen.

Gruss
Thomas