<div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif">> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">That being said, the OpenJDK+CLDR model is incorrect for Irish timekeeping and it really should get fixed at some point. Fractional seconds are a similar sort of thing, though here CLDR has made it clear that they don't care about timestamps before 1990, so this issue should not affect CLDR (unless North Korea starts using a fractional-second UTC offset :-) and only a trivial change to OpenJDK should be needed.</span></div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I still fail to see why you think this is the case. With the current TZDB, in CLDR and clients that use it, <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">for English</span>:</span></div><div class="gmail_default"><ul><li style="font-family:"times new roman",serif">the time in July in Ireland is called "Irish Standard Time" (with abbreviation IST in <span style="color:rgb(34,34,34);font-family:"times new roman",serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">en-IE</span>)<br></li><li><font face="times new roman, serif">the time in December in Ireland is called "Greenwich Mean Time" (with abbreviation GMT)</font></li></ul></div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">What exactly is incorrect about this?</span></div><div class="gmail_default" style="font-family:"times new roman",serif"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div></div><div class="gmail_extra"><br clear="all"><div><div 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 class="gmail_quote">On Fri, Feb 9, 2018 at 11:36 PM, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/06/2018 08:13 AM, Stephen Colebourne wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it was never appropriate to merge the time-zones of<br>
multiple different countries (backzone being the result).<br>
<br>
- the change caused LMT values to be lost<br>
</blockquote>
<br></span>
Those LMT values were not significant and their loss was no real loss. The only significant effect that I recall was on test suites, and test suites should not be forcing tzdb to continue to promote invented data.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- downstream consumers had to change logic wrt the meaning of backzone<br>
</blockquote></span>
Downstream consumers don't have worry about backzone. Mostly, they should just not use backzone, as it is outside the scope of tzdb proper and contains data that is not installed by default.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- it was culturally insensitive to not provide a primary Zone entry<br>
for some countries<br>
</blockquote></span>
tzdb focuses on timekeeping practices. We should spend as few of our limited resources as possible to worry about political or cultural sensitivities that have nothing to do with timekeeping proper. Although we cannot exclude politics entirely, we should strive to not complicate the database merely to make political partisans happy, a task that would be never-ending.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Removal of textual short zone names.<br>
<br>
While these names may well have been invented in some cases, the had<br>
often become de facto standards<br>
</blockquote></span>
The few invented abbreviations that became common parlance were kept. The remaining abbreviations lacked sufficient practical justification for a database where the goal is to describe timekeeping practice, not prescribe it.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- downstream consumers had to change logic to handle numeric-style identifiers<br>
</blockquote></span>
Applications like OpenJDK+CLDR that want abbreviations and full names for every time zone needed to maintain their own databases of inventions anyway. For tzdb-style abbreviations, numeric identifiers are more accurate and less error-prone than invented ones, and have been part of the POSIX standard since 2001.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The main archive format was changed from the well-known and widely<br>
supported gz to the niche lz format.<br>
</blockquote></span>
This has not affected downstream consumers, which can continue to use gzip format as before. Support for lzip is easily and freely available on modern platforms, including MS-Windows. Microsoft itself didn't support gzip back in the day, but that didn't mean we shouldn't have used gzip back then.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Negative SAVE values ...<br>
- downstream consumers broke<br>
</blockquote>
The main downstream consumer that broke was OpenJDK+CLDR. The problem was soon rectified, and because OpenJDK+CLDR is an important enough consumer we now have a way in the development version to generate a form of the tzdata source that does not use negative DST offsets. That being said, the OpenJDK+CLDR model is incorrect for Irish timekeeping and it really should get fixed at some point. Fractional seconds are a similar sort of thing, though here CLDR has made it clear that they don't care about timestamps before 1990, so this issue should not affect CLDR (unless North Korea starts using a fractional-second UTC offset :-) and only a trivial change to OpenJDK should be needed.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not one of these changes has added value to the project.<br>
</blockquote></span>
Even if there was no value to you, there is some value to record civil timekeeping more accurately. Different consumers have different needs in this area.<br>
<br>
More importantly, there needs to be a better way for tzdb+OpenJDK+CLDR to accommodate future changes, as there inevitably will be. Of course we should not change things just for the purpose of changing. Conversely, it would not be healthy to have a software system that can never be changed and can never be improved. We should have a reasonable upgrade strategy, as changes will be inevitable.<br>
</blockquote></div><br></div>