<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>My impression is that tzdb has always tried to be historically
correct and this change falls into that category.</p>
<p>If we constrain Paul or any other maintainer to changes which
won't break any currently used implementations then maybe we lose
the possibility of having something that as closely as possible
matches current knowledge - whatever our personal opinions of what
forward/back means.</p>
<p>Would it be more reasonable to derive a 'sanitized' tzdb from the
'real' tzdb which can satisfy the requirements of extant
implementations. It would even be possible to have multiple such
derivations if conflicting requirements appear. This could also be
generated automatically I presume for each release.<br>
</p>
<p>This shouldn't fall on Paul. The responsibility for testing
software lies with the software owners.<br>
</p>
<br>
<div class="moz-cite-prefix">On 1/19/18 13:15, Mark Davis ☕️ wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJ2xs_HMdzKanx4g1k+d9dD67B__kCH0-ZOfQHOaSjWB0CZK-g@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:"times new
roman",serif">> <span
style="font-size:12.8px;font-family:arial,sans-serif">Basically,
I value "practical correctness" much, much, much higher than
"technical correctness" here - I would far prefer the Irish
legislation to change in order to get technical
correctness...</span></div>
<div class="gmail_default" style="font-family:"times new
roman",serif"><span
style="font-size:12.8px;font-family:arial,sans-serif"><br>
</span></div>
<div class="gmail_default"><span style="font-size:12.8px">I
agree, but would go further. I don't think the change did
increase "technical correctness", nor is it mandated by
Irish legislation. Without negative offsets, it is no
problem for any implementation to have the name "Irish
Standard Time" for what they use in the summer (UTC+01:00),
and the name "Greenwich Mean Time" for what they use in the
winter (UTC+0).</span><br>
</div>
<div class="gmail_default"><span style="font-size:12.8px"><br>
</span></div>
<div class="gmail_default"><span style="font-size:12.8px">Mark</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">Mark</div>
</font>
<div>
<div><font face="'times new roman',
serif"><i><span
style="font-style:normal"></span></i></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Fri, Jan 19, 2018 at 10:24 AM, Jon
Skeet <span dir="ltr"><<a href="mailto:skeet@pobox.com"
target="_blank" moz-do-not-send="true">skeet@pobox.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I've been trying to work out when and how to
chime in, but I think Stephen's post is closest to my
view.
<div><br>
</div>
<div>As far as I can tell, Noda Time will technically
work. ZonedDateTime.<wbr>IsDaylightSavingTime() method
will return true for the winter and false for the summer
(from whenever this takes effect, of course - I haven't
checked). That will surprise developers who aren't aware
of this change, and won't surprise developers who <i>are</i> aware
of this change. I don't think I know a better solution
though.<br>
<div><br>
</div>
<div>At a very, very simplistic level, I'd say it's
worth weighing up the pros and cons:</div>
</div>
<div><br>
</div>
<div>Option 1: Keep the change</div>
<div>Pros:<br>
</div>
<div>- "Technically correct" (maybe - I'll assume it is
for the sake of this discussion)</div>
<div>- Doesn't revert anything</div>
<div><br>
</div>
<div>Cons:</div>
<div>- Breaks a lot of code right now</div>
<div><br>
</div>
<div><br>
</div>
<div>Option 2: Defer the change</div>
<div>Pros:</div>
<div>- Existing software keeps working as expected by
most users and developers</div>
<div><br>
</div>
<div>Cons:</div>
<div>- "Technical correctness" is delayed</div>
<div>- Anything which was changed to support 2018a with a
bad Irish-specific fix may get confused again</div>
<div>- We'll never really know when it's safe to apply the
change</div>
<div><br>
</div>
<div><br>
</div>
<div>Option 3: Revert the change forever, possibly
formalizing this</div>
<div>Pros:</div>
<div>- Existing software keeps working as expected by most
users and developers</div>
<div><br>
</div>
<div>Cons:</div>
<div>- At odds with technical correctness</div>
<div><br>
</div>
<div>For me the "keeping working as expected by most users
and developers" is the most important part... even if
developers fix software to "work" and display things
according to Irish legislation, my guess is that it will
confuse a lot of <i>real users</i>.</div>
<div><br>
</div>
<div>Basically, I value "practical correctness" much,
much, much higher than "technical correctness" here - I
would far prefer the Irish legislation to change in
order to get technical correctness...</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Jon</div>
<div><br>
</div>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 19 January 2018 at 08:44,
Stephen Colebourne <span dir="ltr"><<a
href="mailto:scolebourne@joda.org"
target="_blank" moz-do-not-send="true">scolebourne@joda.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks
for the revert, however I disagree that it is an
appropriate<br>
change to make in general.<br>
<br>
The IANA charter of TZDB says:<br>
"To be clear, the TZ Coordinator SHALL NOT set
time zone policy for a<br>
region but use judgment and whatever available
sources exist to assess<br>
what the average person on street would think the
time actually is, or<br>
in case of historical corrections, was."<br>
<a href="https://tools.ietf.org/html/rfc6557"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://tools.ietf.org/html/rf<wbr>c6557</a><br>
<br>
I do not believe that the "average man on the
street" in Ireland<br>
thinks their clocks go back in winter, I think
they believe their<br>
clocks go forward in summer. More specifically,
the project is about<br>
de facto time as perceived by the masses, not what
the legal documents<br>
say.<br>
<span class="m_8993919923324109423HOEnZb"><font
color="#888888"><br>
Stephen<br>
</font></span>
<div class="m_8993919923324109423HOEnZb">
<div class="m_8993919923324109423h5"><br>
<br>
On 19 January 2018 at 08:14, Paul Eggert <<a
href="mailto:eggert@cs.ucla.edu"
target="_blank" moz-do-not-send="true">eggert@cs.ucla.edu</a>>
wrote:<br>
> Philip Paeps wrote:<br>
>><br>
>> Given the number of things this
break, I would suggest backing the change<br>
>> out for now but pointing out in NEWS
that it will come back say one year<br>
>> from now.<br>
>><br>
>> Replace the actual change by a
comment that the current data is inaccurate<br>
>> pending software being fixed.<br>
><br>
><br>
> Thanks, this sounds like a good way to
go. Proposed patch attached, and<br>
> installed into the development version on
GitHub. Presumably there should be<br>
> a 2018c release quite soon, to get this
temporary workaround out the door.<br>
> (2018b has been prepared and published
but not announced, since the problems<br>
> with ICU and OpenJDK became apparent
during the post-publication process.)<br>
><br>
> There is a conflict between the goals of
"let's not break anything" and<br>
> "let's match civil timekeeping practice".
I lean towards doing the latter as<br>
> long as it doesn't cause too much trouble
for the former. Here it seems like<br>
> there is some trouble with ICU and
OpenJDK, so delay seems advisable until<br>
> fixes can be prepared. That being said, I
don't want to wait indefinitely<br>
> for these fixes. This is not a
tzdb-specific issue, since POSIX requires<br>
> support for negative DST (e.g.,
TZ='IST-1GMT0,M10.5.0,M3.5.0/1<wbr>' for
current<br>
> Irish rules), which means that
applications that reject negative DST are not<br>
> portable to standard platforms configured
for Irish time.<br>
><br>
> The proposed patch continues to use the
"IST is standard time" approach for<br>
> Irish timestamps between October 1968 and
October 1971, but I assume that's<br>
> OK since that's what we did before.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>