wrong Europe/Dublin dst offset rule
Hi, 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. DST either start and end . # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT Rule Eire 1981 max - Mar lastSun 1:00u 0 IST Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT Please explain why -ve dst offset compared with other files. Regards, Vaibhav
Hi, 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. DST either start and end . # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT Rule Eire 1981 max - Mar lastSun 1:00u 0 IST Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT Please explain why -ve dst offset compared with other files. Regards, Vaibhav
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 how the dst be negative.. it is always 0 or +1. we are facing issues because on this.. please correct the dst for europe/dublin. On Sat, 20 Jan 2018, 03:08 Paul Eggert, <eggert@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?
On 2018-05-30 17:16:46 (+0530), Vicky wrote:
On Sat, 20 Jan 2018, 03:08 Paul Eggert, <eggert@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
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@trouble.is> wrote:
On 2018-05-30 17:16:46 (+0530), Vicky wrote:
On Sat, 20 Jan 2018, 03:08 Paul Eggert, <eggert@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
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@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@trouble.is> wrote:
On 2018-05-30 17:16:46 (+0530), Vicky wrote:
On Sat, 20 Jan 2018, 03:08 Paul Eggert, <eggert@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
participants (5)
-
Ben Fortuna -
Paul Eggert -
Philip Paeps -
Stephen Colebourne -
Vicky