On 2/22/19 10:01 AM, Florian Weimer wrote:
Note that the more thorny issue is this one:
<https://bugs.openjdk.java.net/browse/JDK-8212684> <https://bugs.openjdk.java.net/browse/JDK-8212970>
The current API follows POSIX and its requirements on hourly offsets, and tzdata is no longer compatible with the POSIX specification of TZ rules.
As far as I know this is currently an issue only with America/Godthab, Asia/Jerusalem, and Pacific/Fiji, all of which use rules for future timestamps that cannot be expressed using POSIX TZ strings. I don't know what the various TZUpdater/JDK combinations do with this. This issue with non-POSIX TZ strings has been present since tzcode 2013e. It is not directly connected to the more-recent kerfuffles about negative DST (as POSIX allows negative DST) and about a 25:00 time-of-day (as the current data's 25:00 can be simulated with a POSIX TZ string). Here are the TZ values in question. They use Internet RFC 8653 section 3.3.1's extensions to POSIX TZ strings. America/Godthab <-03>3<-02>,M3.5.0/-2,M10.5.0/-1 Asia/Jerusalem IST-2IDT,M3.4.4/26,M10.5.0 Pacific/Fiji <+12>-12<+13>,M11.1.0,M1.2.2/123