[tz] Unexpected last transition in Africa/Casablanca
Paul Eggert
eggert at cs.ucla.edu
Thu May 19 20:48:18 UTC 2022
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.
More information about the tz
mailing list