Vers. 3.3 Datum Eingabe in Liste nicht möglich

[Arno]

Hallo Gemeinde!
RouteConverter 3.3
Die Eingabe eines Datums ins Datumfeld der GPX-Liste wird mit der Fehlermeldung "Konnte Datum '2026-03-22' nicht erkennen da es nicht dem erforderlichen Format 'y-MM-dd' entspricht. Die Eingabe entspricht doch aber genau dem geforderten Format.
In der vorherigen Version gibt's da keine Probleme. Die neue Version läuft mit den gleichen Einstellungen.
MfG Arno

[lundefugl]

Hallo Arno

Kannst du einige Infos zu deinem System noch geben ?
Konkret: Was hast du für eine Sprache eingestellt ? Ich meine speziell im Routeconverter und auch im darunterliegendem System. Hast du Linux, Windows und was für eine Java-Version nutzt du ?

Ich versuche gerade zu verstehen, wo das komische Format herkommt. Ein einzelnes y ist nicht zulässig nach Java-Definition und dürfte das Problem bei dir sein.

Zwischen beiden Versionen gab es eine Änderung beim Verhalten bezüglich Interpretation des Datums (lokale Zeitzone und nicht UTC). Auf das Parsing hätte das nur keinen Einfluss haben sollen.

Danke
Thomas

[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

[lundefugl]

Hallo Christian

Wenn man sich alle Java-Locales ausgeben lässt, dann sind noch viel mehr Sprachen betroffen.
Es war scheinbar bis jetzt eher Zufall und Glück, dass keine System-Locale bei den Anwendern darunter war.

ich sehe 3 Varianten, wie man das in den Griff bekommen könnte.

1. Man merkt sich die System-Locale beim Start und baut auf Basis von dem Pattern das SimpleDateFormat zur Laufzeit.
   Das das zur Laufzeit neu gebaut wird, liegt ja nur daran, dass die Zeitzone jetzt beim Parsen berücksichtigt werden muss.
   Die Variante ist in meinen Augen aber die schlechteste Lösung, da sie eine tickende Zeitbombe ist, bis irgendein Anwender mal dann doch so eine problematische System-Locale hat.
   
   
2. Man definiert die Pattern in den Properties-Dateien, in denen die Übersetzungen drin sind.
   Vorteil, man muss nicht viel anpassen am Bestandscode. Nachteil: Die Übersetzungsfiles müssen redundant die Pattern definieren.
   
   
3. Man stellt vom SimpleDateFormat, welches nicht mehr gepflegt wird, auf DateTimeFormatter um.
   Angeblich tritt dort das Problem nicht auf (was ich noch nicht geprüft habe).
   Vorteil: das wäre wohl die sauberste Lösung. Nachteil: Hier wären vermutlich die meisten Anpassungen im RC notwendig. Wie gross diese sind, kann ich im Moment nicht überblicken, da du das eigentlich recht gut gekapselt schon hattest. 
   

Ich werde mal Variante 3 in einem Branch bei mir probieren. Mal sehen, wo es überall Anpassungen braucht.
Leider kann ich den Fehler bei mir nicht reproduzieren. Ich habe mal versucht eine andere Sprache auszuwählen, aber damit startet der RC nicht mehr.
Da kommt eine java.util.MissingResourceException. Scheinbar fehlen da einige Übersetzungen bei mir.
Der Key "revert-positions-action" ist scheinbar nur in Deutsch, Englisch und Tamilisch (?) (Sprachkürzel ta) vorhanden. Und bei Ta fehlt danach der Key "snap-to-road-action".

Gruss
Thomas

[lundefugl]

Variante 3 kann man schon umsetzen. Leider ist da dann der Parser etwas strenger. D.h. wenn man zweistellig ausgeben will zur Formatierung, dann will der Parser auch zwingend zweistellig haben. D.h. man muss dann führende Nullen immer zwingend eingeben, was blöd ist. Ich bin noch etwas am schauen, ob es da eine elegantere Variante gibt.