On 01/22/2018 10:47 AM, Stephen Colebourne wrote:
This will happen in the perfect scenario where everything is updated at once. The problem is that the perfect scenario is the anomaly. In many perfectly reasonable scenarios, one will be updated without the other being updated, causing nonsense output.
Could you be more precise about what the "one" is, and what the "other" is? Is "one" the Java 9 code, and the other the timezone data being supplied to the Java 9 runtime? For example, does the Java 9 code have time zone abbreviations wired into it? and if not, then what sort of discrepancies would be observed at the API level if (say) the Java code is updated but the Java timezone data are not? I'm not worried about the old Java code here; it can continue to use old-format Java tables if that is needed. I'm worried about what would be the problems when using Java code that has been updated to support negative DST, when this new code is given updated timezone data.
Moreover, having the operating system (via zic) run on different rules to the applications that run it seems destined to end in tears. That bridge was crossed long ago, it seems, if Java-based applications have long been reporting information for old Irish timestamps that disagrees with what GNU/Linux, FreeBSD etc. report for the same timestamps. If we could fix future Java implementations to support negative DST offsets, it appears that we could remove some of these longstanding minor discrepancies between Java and other implementations.