threetenbp: Parse exception when parsing date with time-zone name

Question

I am trying to parse dates in the format of EEE, dd MMM yyyy HH:mm:ss zzz, so for example strings like "Tue, 16 May 2017 07:44:48 GMT" using threeten's DateTimeFormatter. However, it seems that the time-zone name can't get parsed for some reason (I tried to parse the same string just without the time-zone name part and that worked).

Here is the parsing part of the code:

DateTimeFormatter parseFormatter = DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss z", Locale.ENGLISH);
ZonedDateTime parsedDate = ZonedDateTime.parse(date, parseFormatter);

And I get the following error:

org.threeten.bp.format.DateTimeParseException: Text 'Tue, 16 May 2017 13:02:16 GMT' could not be parsed at index 26

I tried all sorts of different formats for the time-zone name part (e.g. z, zzz, Z, ZZZ), but nothing worked. Again, if I parse a substringed date without the time-zone name part (into LocalDateTime), then it works, so I am sure that the problem is somehow with the time-zone name. Does anyone have any idea what the problem might be?

Answer 1

I don’t know why your code didn’t work. It does when I use the java.time classes in my Java 8. So this is just a guess at a possible fix:

    DateTimeFormatter parseFormatter = DateTimeFormatter.RFC_1123_DATE_TIME;
    ZonedDateTime parsedDate = ZonedDateTime.parse(date, parseFormatter);

You will notice it is a slight simplification at the same tine.

DateTimeFormatter.RFC_1123_DATE_TIME is documented as

Returns the RFC-1123 date-time formatter, such as 'Tue, 3 Jun 2008 11:05:30 GMT'.

So I figure it should accept GMT as a time zone name. I should say it fits your date string, and it too works on my computer. I believe this formatter uses English abbreviations for day of week and month no matter the locale (or you could try DateTimeFormatter.RFC_1123_DATE_TIME.withLocale(Locale.ENGLISH), but I really don’t think it would be necessary).

That said, they say you should avoid the three and four letter time zone abbreviations. Some are ambiguous and some are not full time zones, which leads to further ambiguity. While GMT is not the most dangerous one, a rock solid solution to your problem would be if you could get your date string with an offset, such as +00:00 or just Z, instead of the three letter zone name.

See both examples, from the Question and from this Answer, running live at IdeOne.com. Both succeed.