<tt><font size=2>Guy Harris <guy@alum.mit.edu> wrote on 01/24/2018
05:17:24 PM:<br>
<br>
> From: Guy Harris <guy@alum.mit.edu></font></tt>
<br><tt><font size=2>> To: Yoshito Umaoka <yoshito_umaoka@us.ibm.com></font></tt>
<br><tt><font size=2>> Cc: Stephen Colebourne <scolebourne@joda.org>,
Time Zone Mailing <br>
> List <tz@iana.org>, tz <tz-bounces@iana.org></font></tt>
<br><tt><font size=2>> Date: 01/24/2018 05:17 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [tz] OpenJDK/CLDR/ICU/Joda issues
with Ireland change</font></tt>
<br><tt><font size=2>> <br>
> On Jan 24, 2018, at 1:17 PM, Yoshito Umaoka <yoshito_umaoka@us.ibm.com>
wrote:<br>
> <br>
> > CLDR XML (or JSON) data is consumed by other projects such as
ICU <br>
> and Java, and these external projects know those offsets.<br>
> > CLDR only specifies daylight saving time name used for Europe/<br>
> Dublin is "Irish Standard Time".<br>
> > ICU/Java imports zoneinfo from tz database, and obtain offset
at a<br>
> given time, then decide whether it's in standard time or daylight
time.<br>
> <br>
> The tz binary database has, for all transition times, an indication
<br>
> of whether, after the transition, you are in "DST".  If
the tz <br>
> binary database is what Java time zone code imports, it doesn't need<br>
> to look at offsets to determine whether the times are standard or
<br>
> "DST", it can just use those values.  (I say "DST"
because that's <br>
> used to set tm_isdst.)<br>
> <br>
</font></tt>
<br><tt><font size=2>I cannot speak for Java.</font></tt>
<br><tt><font size=2>ICU does not use the tz binaries - ICU generates own
binary resources</font></tt>
<br><tt><font size=2>for tzdata source files. The information equivalent
to tm_isdst is stored</font></tt>
<br><tt><font size=2>in the ICU binary format. In addition to this, ICU
also store raw-offset</font></tt>
<br><tt><font size=2>and DST saving amount, that is not available in the
tz binaries. ICU preserve</font></tt>
<br><tt><font size=2>the information for supporting some legacy APIs -
getRawOffset, etc..</font></tt>
<br>
<br><tt><font size=2>> It does *not* contain any offsets other than,
for each transition, <br>
> what the offset from UTC is.  Thus, it provides no notion of
"raw-<br>
> offset" vs. "actual-offset", and you can't determine
both a "raw-<br>
> offset" and an "actual-offset" from the tz binary database
without <br>
> either 1) additional data or 2) some possibly-incorrect assumptions
<br>
> being made, such as "the only reason why an entry in the table
of <br>
> transitions has a different tt_gmtoff value is that the transition
<br>
> represents starting or ending DST" (that latter assumption has
been <br>
> false for a very very very very very long time for some tzdb <br>
> regions, as a given region might switch from one time zone to another).<br>
> <br>
> The tzdb *source* files, however, give the "standard" offset
from <br>
> UTC in zone lines and the "amount to save", to be added
to the <br>
> "standard" offset, in rule lines, so code that parses those
files <br>
> independently, rather than relying on the binary files produced by
<br>
> zic parsing the files, can get both the "standard" and "current"
<br>
> offset from UTC.<br>
</font></tt>
<br><tt><font size=2>Correct. As I explained above, ICU modified zic also
store raw (standard)</font></tt>
<br><tt><font size=2>offset and DST amount.</font></tt>
<br>
<br><tt><font size=2>> <br>
> Which of those two things does the Java code that "imports zoneinfo
<br>
> from tz database do?  Does it read the binary data, or independently<br>
> read the source data (or read binary data produced by a parser otherthan
zic)?</font></tt>
<br>
<br><tt><font size=2>CLDR and ICU are two separate projects, although CLDR
was originally a</font></tt>
<br><tt><font size=2>part of ICU project historically.</font></tt>
<br>
<br><tt><font size=2>Our biggest issue with the change in 2018a/b was not
actually negative</font></tt>
<br><tt><font size=2>DST offset. The bigger issue is swapping standard/daylight
saving names.</font></tt>
<br><tt><font size=2>(Although, it's still a problem to adopt such rule,
because we have a bug</font></tt>
<br><tt><font size=2>in our code invalidating the negative DST saving amount
in all ICU</font></tt>
<br><tt><font size=2>versions released in the past, and need to distribute
a patch to handle</font></tt>
<br><tt><font size=2>such case.)</font></tt>
<br>
<br>
<br><tt><font size=2>At this moment, the TZ database project does nothing
with i18n. Names</font></tt>
<br><tt><font size=2>used for displaying time zones are pretty much US
centric. But there are</font></tt>
<br><tt><font size=2>many other external projects that want to utilize
the rules for clock</font></tt>
<br><tt><font size=2>changes. CLDR is trying to provide localized expression
of time zone names</font></tt>
<br><tt><font size=2>in various different languages.</font></tt>
<br>
<br><tt><font size=2>CLDR sets an assumption that name of zones are very
stable. For example,</font></tt>
<br><tt><font size=2>"Pacific Standard Time" represents standard
time used on US Pacific coast</font></tt>
<br><tt><font size=2>and the name itself does not change time to time.</font></tt>
<br>
<br><tt><font size=2>However, transition rules are changing much more frequently,
thus there</font></tt>
<br><tt><font size=2>are many releases of new tz database.</font></tt>
<br>
<br><tt><font size=2>To localize time zone display name, CLDR needs to
assign a unique key to</font></tt>
<br><tt><font size=2>each translatable text. And CLDR uses a combination
of zone ID and</font></tt>
<br><tt><font size=2>standard/daylight difference.</font></tt>
<br>
<br><tt><font size=2>Because names are assumed as very stable, a consumer
of CLDR usually does</font></tt>
<br><tt><font size=2>not provide a mechanism to distribute updated names.</font></tt>
<br>
<br><tt><font size=2>Of course, if CLDR and ICU are one project and data
is only consumed by</font></tt>
<br><tt><font size=2>ICU, then it's relatively easy to adopt such change.
We just need to</font></tt>
<br><tt><font size=2>update zone name data and code handling the clock
at the same time.</font></tt>
<br>
<br><tt><font size=2>But they are two separate projects, and CLDR is consumed
by numbers of</font></tt>
<br><tt><font size=2>other projects, that does not have any controls for
clock calculation.</font></tt>
<br><tt><font size=2>So such change could easily break downstream consumers,
who utilizes the</font></tt>
<br><tt><font size=2>TZ database.</font></tt>
<br>
<br><tt><font size=2>I'm not sure what we want to do in CLDR if this change
is brought back</font></tt>
<br><tt><font size=2>to the TZ database at this moment. CLDR technical
committee may decide</font></tt>
<br><tt><font size=2>not to make corresponding change, instead, we might
just change the</font></tt>
<br><tt><font size=2>definition of keys assigned to each zone name strings.</font></tt>
<br>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Yoshito (ICU/CLDR)</font></tt>
<br>
<br>
<br>
<br>
<br><tt><font size=2><br>
</font></tt>
<br>