<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">> <span style="font-family:Arial,Helvetica,sans-serif">CLDR+Java cannot handle</span><span style="font-family:Arial,Helvetica,sans-serif"> </span><span style="font-family:Arial,Helvetica,sans-serif">Irish time correctly for past timestamps</span></div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">We have not seen any demand for names before 1970, thus we haven't designed for more than two (regular) offsets per year for a given zone. It would not be hard, however, to add additional offsets, either for historic times, or if for some reason that becomes fashionable in the future.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">(Luckily, the tendency seems to be in the other direction, collapsing from 2 offsets into 1.)</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 8, 2019 at 9:20 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Steve Summit wrote:<br>
> I'm not sure that's an entirely fair challenge, though.<br>
> Given that (as I understand it) Java and ICU/CLDR use tt_isdst<br>
> to decide whether to display their equivalents of "GMT" or "IST",<br>
> I don't think they *can* get the right answer near 1970<br>
<br>
Yes, Ireland in 1970 is an "unfair" challenge. That was its point. It was <br>
intended to illustrate the inadequacy of the current CLDR/Java model to <br>
represent real-world aspects of civil timekeeping.<br>
<br>
> tzdb changed its mind about the mapping at that point.<br>
<br>
I'm not sure what you mean by "mapping", but the 2018a change to Irish data was <br>
in response to a bug report about Irish time, a bug report that was investigated <br>
and found to be valid. Since tzdb can represent the Irish data as per Irish law <br>
and common use, the change was warranted from the tzdb point of view. And since <br>
Java's TZUpdater program currently rejects the changed data, I developed a <br>
'rearguard' option to tzdb that lossfully converts the main-format tzdata into a <br>
rearguard format that pacifies TZUpdater.<br>
<br>
However, even with the rearguard option (and even if we go back to circa 2017 <br>
code and data before this latest kerfuffle started), CLDR+Java cannot handle <br>
Irish time correctly for past timestamps due to what appear to be shortcomings <br>
in its model. This problem is not limited to Irish time; it also occurs for time <br>
in Los Angeles during World War II (see example below) and in several other <br>
areas, including Morocco right this minute and quite possibly in North America<br>
and Europe in the near future.<br>
<br>
$ jshell<br>
| Welcome to JShell -- Version 12.0.1<br>
| For an introduction type: /help intro<br>
<br>
jshell> var jan1943 = java.time.Instant.ofEpochSecond(-852051600)<br>
jan1943 ==> 1943-01-01T07:00:00Z<br>
<br>
jshell> var zone = java.time.ZoneId.of("America/Los_Angeles")<br>
zone ==> America/Los_Angeles<br>
<br>
jshell> var dtf = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd <br>
HH:mm:ss Z z (zzzz)")<br>
dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)' <br>
''('ZoneText(FULL)')'<br>
<br>
jshell> jan1943.atZone(zone).format(dtf)<br>
$4 ==> "1943-01-01 00:00:00 -0700 PDT (Pacific Daylight Time)"<br>
<br>
jshell><br>
$ TZ=America/Los_Angeles date -d@-852051600 +"%s %Y-%m-%d %H:%M:%S %z %Z"<br>
-852051600 1943-01-01 00:00:00 -0700 PWT<br>
<br>
Near the end of the example above, Java says "PDT" where tzdb says "PWT", <br>
because Java can't handle PWT.<br>
<br>
> Now, it's true, isdst might not be the best key to use for this<br>
> sort of thing any more. Do we have recommendations for what<br>
> projects like Java and ICU/CLDR ought to be keying off of,<br>
> if not isdst? (I suppose tt_abbrind, or more likely the actual<br>
> string it indexes, might be better.)<br>
<br>
I'm afraid they will need to solve this problem largely on their own, as one <br>
cannot look at tzdata and automatically derive strings like "Pacific War Time" <br>
or "Central Africa Ramadan Time": those strings are not in the data (not even in <br>
English), and there are no numeric equivalents either. The only <br>
partially-relevant info in tzdata consists of abbreviations like "IST" and "PDT" <br>
and unfortunately these abbreviations are well-documented to be ambiguous and <br>
historically inaccurate in some cases.<br>
<br>
It should be possible for CLDR+Java to develop reasonably-reliable heuristics <br>
for guessing what string to use in some cases. For example, they could have a <br>
heuristic that "IST" means "India Standard Time" in Asia/Kolkata, "Israel <br>
Standard Time" in Asia/Gaza, Asia/Hebron and Asia/Jeruslaem, "Irish Summer Time" <br>
in Ireland before 1968-10-27, and "Irish Standard Time" in Ireland starting <br>
1968-10-27. Similar heuristics could be used for other abbreviations, and if <br>
CLDR+Java tune the heuristics enough they'd be accurate. However, they'd have to <br>
do most of this work on their own. For example tzdb does not have an alphabetic <br>
abbreviation for the current time in Morocco (+00, a 1-hour negative DST where <br>
standard time is +01), so CLDR would have to invent an abbreviation there <br>
(presumably something like "Central Africa Ramadan Time" in English) and base <br>
its use on a heuristic like "when Africa/Casablanca is at +00 in the year 2019 <br>
or later, its time zone abbreviation is 'Central Africa Ramadan Time'".<br>
</blockquote></div>