An illustrating example: If the rule line contains an optional meta-column at the end whose content is a key-value-structure (comma-separated in case of several entries for any other purpose) then the Eire-rules might look like this: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S META Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT category=winter Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST category=summer If the new META-column is missing at all or if its content does not contain an entry with key "category" (you are free to use a better key) then other tzdb-source-file consumers like Java or ICU are free to continue the assumption that winter time is to be determined by evaluating SAVE = 0 (current practice). Note that these consumers cannot evalute the column LETTERS/S as that column has no clear stable keys ("IST" would be specific for Ireland only and does not enable a general evaluation if it is connected to summer period). Then: After such a change, a source-file-tzdb-compiler can use this new information to determine the right entry in CLDR-data. If the value of key "category" is "winter" then use the CLDR-entry <standard>Greenwich Mean Time</standard> for getting the right time zone name (we leave out here the fact that CLDR does not support historized tz names but that is another problem not really related to this topic). If the value of key "category" is "summer" then use the alternate CLDR-entry <dailight>Irish Standard Time</daylight>. The new source format enhancement of tzdb only needs to be documented and should use standardized values like "winter", "summer" (or even "ramadan"). This way, CLDR-data don't even need to be changed at all so it is completely backwards compatible. The ICU- and Java-compilers would need a grace period to adjust their compilers and their own binary tz-format to process the new available informations (which should be not so difficult). If ICU or OpenJDK (Java) are still unwilling to change their current implementation then introducing negative dst offsets will inevitably break the way they determine the right tz label (resulting in "Irish Standard Time" in winter). But it would be their problem and responsibility. IMHO downstream consumers should be flexible and are expected to be flexible if they get the chance to fix their products after having got new informations in the tzdb source file format. I have adjusted my tzdb-compiler (Time4J) such that it looks if all rule lines referencing the same name (here: Eire) contain any negative dst offsets. If yes then let's assume summer time for SAVE=0 and winter time for SAVE < 0. So I can still work with old unchanged CLDR-entries for getting "Irish Standard Time" in summer. Although I am not quite sure if this way of fixing is stable enough for the future it demonstrates that it is possible for downstream consumers to cope with negative dst offsets already now. My proposal serves for making the handling of negative dst offsets easier and more stable. If any downstream consumers are still unwilling to handle negative dst offsets then it is just laziness for me. With best regards Meno Am 25.01.2018 um 22:53 schrieb Paul Eggert:
I'm afraid that I'm not understanding the proposal; could you write up Irish time as a specific example to help explain it? Remember, the problem is not whether Java can be changed to support negative DST offsets (or, for that matter, whether it can be changed to support the new feature you're proposing). The problem is how to transition from the old to the proposed system without breaking anything significant, even when some components are old and some are new.