[tz] wrong Europe/Dublin dst offset rule

Stephen Colebourne scolebourne at joda.org
Wed May 30 18:17:18 UTC 2018


Most of the Java world will be reverting the negative DST values by
applying hacks when parsing the source data. As such, Java tools will
continue to see positive DST.

The JDK is using rearguard until the necessary hack is applied.
https://bugs.openjdk.java.net/browse/JDK-8195595

Joda-Time has had the hack applied and is released as of today with 2018e.

ThreeTen-Backport is not done.

Time4J https://github.com/MenoData/Time4J/issues/742

Stephen


On 30 May 2018 at 13:16, Ben Fortuna <benfortuna at gmail.com> wrote:
> Hi all,
>
> I can confirm this had also presented issues for the ical4j Java library.
>
> I'm trying to identify a fix but looks like it the issue may be in the jdk
> itself (Paul mentioned openjdk had some issues?)
>
> If anyone has a link to track the Java issue it would be much appreciated.
>
> Regards,
> Ben
>
>
> On Wed., 30 May 2018, 9:54 pm Philip Paeps, <philip at trouble.is> wrote:
>>
>> On 2018-05-30 17:16:46 (+0530), Vicky wrote:
>> >On Sat, 20 Jan 2018, 03:08 Paul Eggert, <eggert at cs.ucla.edu> wrote:
>> >> On 01/19/2018 12:53 AM, Vicky wrote:
>> >> > while parsing the data i found the issue in rule Europe/Dublin
>> >> > Negative DST.. Previous version or not in any other file there is no
>> >> > negative dst.
>> >>
>> >> Yes, although negative DST support is required by POSIX and has been in
>> >> tzcode for quite some time, that was the first use of it in tzdata.
>> >> That
>> >> change was intended to support Irish Standard Time, which is an hour
>> >> ahead of GMT (which Ireland uses in winter). We're planning to back
>> >> that
>> >> change out temporarily, since we found some issues with it with ICU and
>> >> with OpenJDK.
>> >>
>> >> What software are you using to parse the data files? Has the problem
>> >> been reported to the maintainers of that software?
>> >
>> >In current version also dst is -ve for europe/dublin
>>
>> This is correct.
>>
>> >how the dst be negative.. it is always 0 or +1. we are facing issues
>> >because on this..
>>
>> Please read through the several threads on this mailing list about this
>> topic since December/January.  I don't believe there is any benefit to
>> having the discussion again.
>>
>> >please correct the dst for europe/dublin.
>>
>> If you can't correct your software to correctly parse tzdb files with
>> negative dst, you can use the "rearguard" format of tzdb.
>>
>> As discussed (at length) though: negative dst is an unfortunate reality
>> which your software should be able to deal with.
>>
>> Philip
>>
>> --
>> Philip Paeps
>> Senior Reality Engineer
>> Ministry of Information


More information about the tz mailing list