[tz] Irish Standard Time vs Irish Summer Time

Ken Murchison murch at fastmail.com
Fri Jan 19 15:28:19 UTC 2018


FWIW, vzic (at least the fork that is in libical) handles the negative 
offset just fine, although having "winter" time show up in a "daylight" 
component looks odd:

BEGIN:STANDARD
TZNAME:IST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
DTSTART:19810329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:STANDARD

BEGIN:DAYLIGHT
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
DTSTART:19961027T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:DAYLIGHT


On 01/18/2018 03:32 PM, Stephen Colebourne wrote:
> This also broke Java:
> https://bugs.openjdk.java.net/browse/JDK-8195595
> and no doubt also breaks ThreTen-Backport and Joda-Time (I don't have
> time to test them right now).
>
> As I and others have indicated before, this change should not have
> happened. The likelihood of it breaking something was always very
> high, and the alleged reality is that it expresses is a fact that is
> irrelevant to most users (and is disputed anyway). This was change for
> changes sake.
>
> The real problem here is the incessant fiddling with the data. The
> vast majority of users just want small stable updates representing
> actual changes in time zones, not the continuous refactoring we've
> been subjected to in the last few years.
>
> Stephen
>
>
> On 18 January 2018 at 20:24, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
>>
>>> currently-shipping versions of ICU cannot deal with negative DST offsets;
>>> they will refuse to accept the data (illegal argument error).
>>
>> Could you give more details? Is the problem with code that reads tzdb source
>> files, or with code that reads binary files produced by zic? How can I
>> reproduce the problem from the ICU source code? Is there a
>> publicly-available bug report about the problem? (I looked for one in
>> <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find it.)
>> That sort of thing.
>>
>> I'm asking for these details because there may be a way to implement Irish
>> standard time while avoiding the specific problem that the ICU code is
>> running into.
>>
>>> Would it be possible to roll this change out and plan to reintroduce it in
>>> the future, along with the changes needed in ICU and CLDR? (As well as a
>>> plan to deploy the updated ICU/CLDR to the field). I would also be OK with
>>> just backing it out period, but if we’re going to keep this change we need
>>> time for ICU and CLDR to adjust.
>>
>> If the problem is serious enough and cannot be worked around, we could back
>> out the change in the next tzdb release and then re-add the change later,
>> once things have settled down.
>>
>> I'm concerned as to why this problem wasn't discovered until now. The change
>> for Ireland has been in the development repository since December 7 and was
>> circulated for comments, and the only specific problem reported for it was
>> so trivial that it was not worth worrying about. If ICU depends in crucial
>> ways on undocumented properties of tzdb, then ICU maintainers need to
>> monitor this mailing list and/or run tests based on the development
>> repository, and do that on a regular basis. Otherwise further problems like
>> this will be inevitable.
>>

-- 
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd



More information about the tz mailing list