[tz] Unexpected last transition in Africa/Casablanca

[Paul Eggert]

On 5/19/22 05:54, Stephen Colebourne wrote:

> Key here is that Java (and thus indirectly Android) and ICU take
> backwards compatibility more seriously than TZDB.

TZDB is upward compatible with POSIX, whereas from what others are 
saying it appears that Java's old API is not compatible because the 
implementation doesn't support negative DST. This doesn't sound like 
Java and ICU treat "backwards compatibility more seriously"; on the 
contrary, it sounds like the Java implementation is gratuitously 
incompatible with a standard that predates Java by several years.

Almaz writes that Java's newer APIs can handle POSIX TZ strings so it 
appears Java's newer APIs are in better shape, which would be a good thing.

Though I'm still puzzled as to why Java's old API can't support negative 
DST so as to be compatible with POSIX. A java.util.Timezone object's 
getDSTSavings method could return a negative integer just as easily as a 
positive one. Sure, some old code might break if getDSTSavings returns 
any value other than the usual 3600000 milliseconds, but the same old 
code might break if getDSTSavings returns 1800000 rather than 3600000 
(which is something it *can* do now) so it shouldn't be a big deal for 
it to return -3600000 either.