DateTimeFormatter parsing - timezone names and daylight savings overlap times

It seems like a bug. I tested in Java 17 and it's still the same behaviour. I dug into the parsing logic and I can see why this happens.

One of the first things that happens is TimeZoneNameUtility.getZoneStrings(locale) is called. This gives you a 2D array of Strings

[ [ "Europe/Paris", "Central European Standard Time", "CET", "Central European Summer Time", "CEST", "Central European Time", "CET" ], // others ] 

It builds a prefix tree out of them. All items in here get mapped to the 0th item - "Europe/Paris". When it's parsing, it descends the prefix tree one character at a time e.g. C... E... T..., then returns a match if there was one. Since CEST and CET map to the same thing, they're effectively just aliases of one another.

Later on that string is passed to ZoneId.of() which means the fact of whether it's summertime or not has been thrown away.

It does seem in Java 18 that there have been significant changes in this code, so maybe they're addressing that.

The general workaround

JodaStephen, the main author of java.time, in his answer shows a workaround for the case of CET and CEST (Central European Time and Central European Summer Time). I present a workaround that I believe will work in all time zones having different abbreviations for standard time and summer time (DST).

public static ZonedDateTime parse(String text) { ZonedDateTime result = ZonedDateTime.parse(text, FORMATTER); if (result.format(FORMATTER).equals(text)) { return result; } // Default we get the earlier offset at overlap, // so if it didn’t work, try the later offset result = result.withLaterOffsetAtOverlap(); if (result.format(FORMATTER).equals(text)) { return result; } // As a last desperate attempt, try earlier offset explicitly result = result.withEarlierOffsetAtOverlap(); if (result.format(FORMATTER).equals(text)) { return result; } // Give up throw new IllegalArgumentException(); } 

The method could use any formatter with a time zone name or abbreviation as long as it’s supposed to give the same output from formatting as the input it parses (so optional parts are a no-no, for example). I have assumed a formatter equivalent to yours:

private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz yyyy", Locale.ROOT); 

Your trouble was with a millisecond value of 1 477 789 200 000, which was formatted into Sun Oct 30 02:00:00 CET 2016 and then parsed to 1 477 785 600 000 for a difference of -3 600 000 milliseconds. So let’s try my method with that one.

private static final ZoneId TIME_ZONE = ZoneId.of("Europe/Berlin"); long trouble = 1_477_789_200_000L; String formatted = Instant.ofEpochMilli(trouble).atZone(TIME_ZONE).format(FORMATTER); ZonedDateTime zdt = parse(formatted); long parsedTime = zdt.toInstant().toEpochMilli(); System.out.println(formatted + ", diff: " + (parsedTime - trouble)); 

Output is:

Sun Oct 30 02:00:00 CET 2016, diff: 0

But don’t parse three letter time zone abbreviations

All of the above said, even with a workaround for that case of the fall overlap, you are on shaky ground when trying to parse time zone abbreviations. Most of the most common ones are ambiguous, and you don’t know what you get from parsing. In the case of CET and CEST, they are common abbreviations for very many European time zones that at present share offset +01:00 during standard time and +02:00 during summer time, but historically have had their own offset each and are likely to go separate ways again since the EU has decided to give up summer time completely. Next year one time zone may use CET all year and another CEST all year. My code above does not account for that.

Instead simply take the output from ZonedDateTime.toString and parse it back using the one-arg ZonedDateTime.parse(CharSequence).