The bridge stores time as a timestamp + the zone ID. Unfortunately, this representation is ambiguous for some timestamps, in particular when clocks are set back due to switching daylight saving time. For instance "2011-10-30 2:50:00 CET" may point to either "2011-10-30 2:50:00+01:00" or "2011-10-30 2:50:00+02:00".
A safer string representation would be something like what's done in java.time.format.DateTimeFormatter.ISO_ZONED_DATE_TIME, where both the offset and the zone ID are explicitly stored (something like "2011-10-30 2:50:00+01:00[CET]")
Some strategy will have to be chosen to handle previously stored ZonedDateTimes, since we'll have to change the storing format and cannot assume that users will reindex everything.
Attached is a patch adding a test case (but no fix yet).
A related bug in the JDK prevents from doing correct parsing of strings containing both a zone ID and an offset: https://bugs.openjdk.java.net/browse/JDK-8066982
It has been fixed in JDK9, but not in JDK8 yet.
Does Elasticsearch supports it as a date format?
Well, yes, it was even you who asked for it in my PR