Ein Literalstrich, der zu DateTimeFormatterBuilder hinzugefügt wurde, führt dazu, dass das Parsing fehlschlägt

9

Ich versuche ein DateTimeFormatter um dem folgenden Beispiel zu entsprechen (es ist tatsächlich etwas komplexer als das, aber das sollte keine Rolle spielen).

%Vor%

Ich habe Folgendes geschrieben, aber es ergibt sich eine Ausnahme:

%Vor%

Die Ausnahme ist:

%Vor%

Es scheint einen Fehler im Doppelpunkt zwischen 17:45 und DateTimeFormatterBuilder.appendLiteral gibt keine Hinweise.

Wenn ich das Literal in ein anderes Zeichen ändere, sagen wir m , dann funktioniert es gut:

%Vor%

Was ist hier los? Wie kann ich es beheben, vorausgesetzt, ich kann das Format nicht ändern?

Kommentare deuten darauf hin, dass dies versionsabhängig sein könnte. Ich benutze JDK 9.0.1 und es ist wurde auf 9.0.4 reproduziert .

    
Michael 05.03.2018, 11:33
quelle

2 Antworten

8

Dies hat damit zu tun, dass DateTimeFormatter.BASIC_ISO_DATE eine optionale Offset-ID enthält. Anscheinend formatiert Ihr Formatierer -17 als Offset und dann Objekte, weil es einen Doppelpunkt gibt, wo das Format einen Bindestrich benötigt.

Wenn Sie stattdessen m verwenden, kann dies nicht als Offset geparst werden und entspricht daher dem Literal m im Format und alles funktioniert.

Ich habe versucht, Großbuchstaben Z zu verwenden. Z kann auch eine Offset-ID sein.

%Vor%

Jetzt habe ich java.time.format.DateTimeParseException: Text '20180302Z17:45:21' could not be parsed at index 9 . Index 9 uns direkt nach dem Z , so scheint es, dass der Formatierer den Offset analysiert und dann versucht, das Literal Z zu finden, wo 17 ist.

EDIT: Und die Lösung? Anstatt BASIC_ISO_DATE anzuhängen, fügen Sie ein Muster hinzu:

%Vor%

Das Parsen funktioniert jetzt auch auf Java 9.0.4.

EDIT: Um die Optionalität des Offsets zu verdeutlichen:

%Vor%

Dies gedruckt

%Vor%

Also im ersten Fall, wo kein Offset verfügbar ist, wird es einfach weggelassen. Im zweiten Fall, wo einer verfügbar ist, wird er auch gedruckt (ohne Doppelpunkt).

Offene Frage: Warum funktioniert es in Java 8? Ist das wirklich ein Fehler?

Quote:

  
  • Wenn der Offset nicht zum Formatieren oder Parsen verfügbar ist, ist das Format vollständig.
  •   
  • Die Offset-ID ohne Doppelpunkte. Wenn der Offset Sekunden hat, werden sie behandelt, obwohl dies nicht Teil des ISO-8601 ist   Standard. Das Offset-Parsing ist nachsichtig, was die Minuten erlaubt   und Sekunden, um optional zu sein. Bei der Analyse wird nicht zwischen Groß- und Kleinschreibung unterschieden.
  •   

Von die Dokumentation von BASIC_ISO_DATE

    
Ole V.V. 05.03.2018, 12:16
quelle
0

Ich habe dies als Bug angesprochen und es wurde in JDK-8199412 bestätigt.

    
Michael 04.04.2018 10:28
quelle

Tags und Links