The following testcase runs perfectly under Java 10:
import java.time.Instant;
import java.time.format.DateTimeFormatter;
import java.time.format.DateTimeFormatterBuilder;
class Test
{
    public static void main (String[] args) throws java.lang.Exception
    {
        DateTimeFormatter dateFormatter = new DateTimeFormatterBuilder().
          appendPattern("EEE, dd MMM yyyy HH:mm:ss zzz").
          toFormatter();
        Instant result = dateFormatter.parse("Sat, 29 Sep 2018 20:49:02 GMT", Instant::from);
        System.out.println("Result: " + result);
    }
}
but under Java 11 I get:
Exception in thread "main" java.time.format.DateTimeParseException: Text 'Sat, 29 Sep 2018 20:49:02 GMT' could not be parsed at index 0
        at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2046)
        at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1948)
        at Test.main(Test.java:13)
What's going on?
UPDATE: Replacing toFormatter() with toFormatter(Locale.US) fixes the problem. I am guessing this issue is related to https://bugs.openjdk.java.net/browse/JDK-8206980. This issue is marked as fixed in Java 11 build 23 but I am running
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Shouldn't this be fixed in this version?
UPDATE2: If you are unable to reproduce the problem, try replacing toFormatter() with toFormatter(Locale.CANADA).
DateTimeFormatter.RFC_1123_DATE_TIMEYour date-time string is in RFC 822/RFC 1123 format. Instead of building your own formatter use the built-in DateTimeFormatter.RFC_1123_DATE_TIME:
    Instant result = DateTimeFormatter.RFC_1123_DATE_TIME
            .parse("Sat, 29 Sep 2018 20:49:02 GMT", Instant::from);
    System.out.println("Result: " + result);
Output is:
Result: 2018-09-29T20:49:02Z
This RFC 1123 formatter is always in English, as required by the RFC specification. I even tried setting my default locale to Locale.CANADA_FRENCH, and the code still worked.
In Java 11 Java expects that the abbreviations for day of week and for month are written with a dot in Locale.CANADA: Sat. and Sep. rather than Sat and Sep. In Java 10 they are expected without dots, so here parsing works. The difference probably lies in different versions of CLDR data and can hardly be considered a bug in any of the mentioned Java versions. Since Java 9 CLDR has been the default locale data in Java — including what day and month abbreviations look like in different locales.
Demonstration: Using your formatter, but modifying it to use Locale.CANADA as you said:
    DateTimeFormatter dateFormatter = new DateTimeFormatterBuilder().
            appendPattern("EEE, dd MMM yyyy HH:mm:ss zzz").
            toFormatter(Locale.CANADA);
    System.out.println("Sample: " + ZonedDateTime.now(ZoneId.of("America/Toronto"))
            .format(dateFormatter));
Running on Java 10.0.2 this printed no dots:
Sample: Sun, 30 Sep 2018 10:39:28 EDT
And on Java 11 build 11+28:
Sample: Sun., 30 Sep. 2018 10:50:29 EDT
So I believe that the behaviour has nothing to do with the bug report you linked to.
DateTimeFormatter.RFC_1123_DATE_TIME documentationIf you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With