[tz] Irish Standard Time vs Irish Summer Time

Fri Jan 19 18:48:04 UTC 2018

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 
> <mailto: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 <mailto: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
>         <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
>         <mailto: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/77feffea/attachment-0001.html>