Mark Davis ☕️ wrote:
We have not seen any demand for names before 1970
The overall problem is not limited to names before 1970. It has occurred as recently as yesterday in Morocco. This is because until October last year, +00 was standard time and +01 was daylight saving time in Morocco, but now it's the other way around. I presume that Morocco is low priority for Java+CLDR, as this change has not found its way into CLDR+Java yet. OpenJDK 12.0.1's data for Morocco has not been updated since Morocco last changed its rules, and OpenJDK mishandles UTC offsets for Moroccan timestamps as recent as yesterday, as shown in the example at the end of this email. Java+CLDR can get away with a low priority for Morocco, as Morocco is a small part of the market. But it's likely that the issue can't continue to be ignored if North America and/or Europe change their zones as they are threatening to do soon. To some extent Morocco is a canary in the coal mine here, as it jumped the gun on the upcoming EU DST changes. $ jshell | Welcome to JShell -- Version 12.0.1 | For an introduction type: /help intro jshell> var zone = java.time.ZoneId.of("Africa/Casablanca") zone ==> Africa/Casablanca jshell> var time = java.time.Instant.ofEpochSecond(1560011295) time ==> 2019-06-08T16:28:15Z jshell> var dtf = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss Z z (zzzz)") dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)' ''('ZoneText(FULL)')' jshell> time.atZone(zone).format(dtf) $4 ==> "2019-06-08 17:28:15 +0100 WET (Western European Standard Time)" jshell> $ TZ=Africa/Casablanca LC_ALL=C date -d@1560011295 Sat Jun 8 16:28:15 +00 2019 The last line (from tzdb) is correct. In contrast, the Java-generated line "17:28:15 +0100 WET (Western European Standard Time)" is wrong by an hour and its UTC offset is miscalculated as +01, despite the fact that Java's name for the time zone is OK because WET is conventionally an alias for +00.