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.

[lundefugl]

Hallo Christian

Pullrequest ist gemacht und ich hoffe, dass jetzt alles funktioniert. Über Details können wir im Pullrequest ggf. diskutieren. Falls es zu viel wird, dann wäre auch mal einen Call möglich, um das direkt zu besprechen.

Hintergrund der ganzen Überlegung ist nun:

Die ROOT-Locale soll nach meinem Verständnis das Standard-Verhalten vom lokalen Java sein. Deswegen wird nun die Locale beim Start sich noch gemerkt, damit in dem Fall darauf zurückgegriffen werden kann.

Das ganze Formatieren und Parsen habe ich in eine eigene Klasse ausgelagert, für die es ein Interface gibt. Diese basiert jetzt auf der "alten" Zeit-API von Java. Wenn man mal auf die neue API umstellen will (die restriktiver beim Parsen ist und damit andere Probleme verursacht) oder man will das Pattern aus den Sprachfiles des Routeconverters beziehen, so muss nur eine eigene Implementierung gemacht werden und der Rest sollte sich nicht mehr ändern.

Kommt so eine "komische" Formatierung mit einem y, so wird dieses durch zwei yy ersetzt, womit der Parser dann läuft.

Ich habe für alle Varianten mal versucht Unittests zu machen. Schwedisch wird da benutzt, weil das eine Sprache ist, die auch dieses Pattern "y-MM-dd" benutzt.

Gruss & schöne Ostern noch
Thomas

[routeconverter]

Hallo Thomas,

vielen Dank für die ausführliche Recherche. Ich habe den Pull Request angenommen und ein neues Prerelease hochgeladen, das den neuen Code enthält.

Bitte teste(t) und berichtet!

[lundefugl]

Hallo Christian

keine Ursache. Das war ja auch irgendwie mein Bug vom Weihnachts-Merge. Und ausserdem hat mich natürlich der Grund auch brennend interessiert.

Nach über 25-Jahren Java-Entwicklung habe ich dadurch wieder was gelernt. Dass da Java Formate ausspuckt, die es selbst nicht mehr lesen kann, war mir bisher nicht bekannt.
In allen Firmen und Projekten hatten wir den Fall noch nie. Wir haben da immer die Formate über die eigene Lokalisierung vorgegeben, um besser Einfluss auf die Darstellung zu bekommen (mit Sekunden oder ohne usw.). Das man damit diesen Bug (ich nenne es mal so, weil es das für mich ist) umgeht, war einfach Glück.

Bei mir funktioniert die neue Preversion weiter.
Ich habe aber nur deutsche und englische Systeme, wo das Problem auch zuvor nicht aufgetreten ist. Und andere Sprachen kann ich im RC auch nicht auswählen, da ich es dann nicht lesen/bedienen kann.

Für den Test wären andere Spracheinstellungen im RC oder vom Betriebssystem hilfreich. Speziell ein Test von Arno wäre gut, aber er war leider seit seinem Post nicht mehr online.

Gruss
Thomas