[tz] Irish Standard Time vs Irish Summer Time

Fri Jan 19 18:59:04 UTC 2018

There's a huge difference between "this change might possibly break some
implementations" and "we *know* this change will break some very widespread
implementations" or even "we *know* this change will break implementations
which now have fixes in place but where those fixes certainly won't have
been universally adopted".

There's also a huge difference between making a change for correctness that
will have a definite benefit to users, and making a change purely for
*technical* correctness with no palpable user benefit. (And this is
presupposing that it *is* more correct - as Mark said, it's not clear
that's even the case.)

Any change, at any time, where we know it will break real users - whether
that's because of a lack of testing of scenarios which haven't happened
before or not - should only be undertaken when there are *massively* positive
benefits for other users, IMO.
If someone's phone breaks, how much do you think they care whether it's
because of an app developer, a library developer, an OS developer, or the
data provider?

Jon

On 19 January 2018 at 18:48, Michael Douglass <mikeadouglass at gmail.com>
wrote:

> My impression is that tzdb has always tried to be historically correct and
> this change falls into that category.
>
> 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.
>
> 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.
>
> This shouldn't fall on Paul. The responsibility for testing software lies
> with the software owners.
>
> On 1/19/18 13:15, Mark Davis ☕️ wrote:
>
> > 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...
>
> 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).
>
> Mark
>
> Mark
>
> On Fri, Jan 19, 2018 at 10:24 AM, Jon Skeet <skeet at pobox.com> wrote:
>
>> I've been trying to work out when and how to chime in, but I think
>> Stephen's post is closest to my view.
>>
>> As far as I can tell, Noda Time will technically work.
>> ZonedDateTime.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 *are* aware of this
>> change. I don't think I know a better solution though.
>>
>> At a very, very simplistic level, I'd say it's worth weighing up the pros
>> and cons:
>>
>> Option 1: Keep the change
>> Pros:
>> - "Technically correct" (maybe - I'll assume it is for the sake of this
>> discussion)
>> - Doesn't revert anything
>>
>> Cons:
>> - Breaks a lot of code right now
>>
>>
>> Option 2: Defer the change
>> Pros:
>> - Existing software keeps working as expected by most users and developers
>>
>> Cons:
>> - "Technical correctness" is delayed
>> - Anything which was changed to support 2018a with a bad Irish-specific
>> fix may get confused again
>> - We'll never really know when it's safe to apply the change
>>
>>
>> Option 3: Revert the change forever, possibly formalizing this
>> Pros:
>> - Existing software keeps working as expected by most users and developers
>>
>> Cons:
>> - At odds with technical correctness
>>
>> 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 *real users*.
>>
>> 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...
>>
>> Jon
>>
>>
>> On 19 January 2018 at 08:44, Stephen Colebourne <scolebourne at joda.org>
>> wrote:
>>
>>> Thanks for the revert, however I disagree that it is an appropriate
>>> change to make in general.
>>>
>>> The IANA charter of TZDB says:
>>> "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a
>>> region but use judgment and whatever available sources exist to assess
>>> what the average person on street would think the time actually is, or
>>> in case of historical corrections, was."
>>> https://tools.ietf.org/html/rfc6557
>>>
>>> I do not believe that the "average man on the street" in Ireland
>>> thinks their clocks go back in winter, I think they believe their
>>> clocks go forward in summer. More specifically, the project is about
>>> de facto time as perceived by the masses, not what the legal documents
>>> say.
>>>
>>> Stephen
>>>
>>>
>>> On 19 January 2018 at 08:14, Paul Eggert <eggert at cs.ucla.edu> wrote:
>>> > Philip Paeps wrote:
>>> >>
>>> >> Given the number of things this break, I would suggest backing the
>>> change
>>> >> out for now but pointing out in NEWS that it will come back say one
>>> year
>>> >> from now.
>>> >>
>>> >> Replace the actual change by a comment that the current data is
>>> inaccurate
>>> >> pending software being fixed.
>>> >
>>> >
>>> > Thanks, this sounds like a good way to go. Proposed patch attached, and
>>> > installed into the development version on GitHub. Presumably there
>>> should be
>>> > a 2018c release quite soon, to get this temporary workaround out the
>>> door.
>>> > (2018b has been prepared and published but not announced, since the
>>> problems
>>> > with ICU and OpenJDK became apparent during the post-publication
>>> process.)
>>> >
>>> > There is a conflict between the goals of "let's not break anything" and
>>> > "let's match civil timekeeping practice". I lean towards doing the
>>> latter as
>>> > long as it doesn't cause too much trouble for the former. Here it
>>> seems like
>>> > there is some trouble with ICU and OpenJDK, so delay seems advisable
>>> until
>>> > fixes can be prepared. That being said, I don't want to wait
>>> indefinitely
>>> > for these fixes. This is not a tzdb-specific issue, since POSIX
>>> requires
>>> > support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for
>>> current
>>> > Irish rules), which means that applications that reject negative DST
>>> are not
>>> > portable to standard platforms configured for Irish time.
>>> >
>>> > The proposed patch continues to use the "IST is standard time"
>>> approach for
>>> > Irish timestamps between October 1968 and October 1971, but I assume
>>> that's
>>> > OK since that's what we did before.
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180119/a40e5d4f/attachment.html>