<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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:</p>
<table class="highlight tab-size js-file-line-container"
data-tab-size="8">
<tbody>
<tr>
<td id="LC516" class="blob-code blob-code-inner js-file-line">#
Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S META<br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table class="highlight tab-size js-file-line-container"
data-tab-size="8">
<tbody>
<tr>
<td id="LC517" class="blob-code blob-code-inner js-file-line">Rule
Eire 1971 only - Oct 31 2:00u -1:00 GMT category=winter<br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table class="highlight tab-size js-file-line-container"
data-tab-size="8">
<tbody>
<tr>
<td id="LC518" class="blob-code blob-code-inner js-file-line">Rule
Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST category=summer<br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<br>
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).<br>
<br>
Then:<br>
<br>
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").<br>
<br>
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.<br>
<br>
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.<br>
<br>
With best regards<br>
Meno<br>
<br>
<div class="moz-cite-prefix">Am 25.01.2018 um 22:53 schrieb Paul
Eggert:<br>
</div>
<blockquote type="cite"
cite="mid:6e46a0ce-d045-9a6d-40c7-5aa2f2893264@cs.ucla.edu">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.
<br>
<br>
</blockquote>
<br>
</body>
</html>