Investigate implications of negative dst-offsets #742
Milestone
Comments
|
Another aspect: The current Java practice is broken for the years 1968-1971 in Ireland. The result should display "Irish Standard Time", not "GMT". The actual workaround in Time4J using the tzdata-module v2.2-2018b can obtain the desired effect, however. But the tzdb-version v2018c has rolled back the tzdb-fix so Time4J would be broken again (like standard Java) in case of Ireland and years 1968-71. |
|
See also the heated debate on tzdb-mailing list. |
|
For release v5.0, following change must be done: Remove the method The replacement is to move the method in question to the interface |
MenoData
added a commit
that referenced
this issue
Oct 5, 2018
|
Final solution:
A new algorithm inside Timezone.isDaylightSaving(UnixTime) has been realized which fully covers the case of Ireland, even in the years 1968-71. |
sdaoden
added a commit
to sdaoden/s-mailx
that referenced
this issue
Nov 9, 2021
Andrea (thanks!) reported to the ML: Looking at the source of s-nail, I tracked it all down to a naive/incorrect handling of tm->tm_isdst in mkdate() in sendout.c (the same logic appears in other places, for example see the comment in src/mx/header.c that reads "/* TODO simply adding an hour for ISDST is .. buuh */".) Yeah the issue was known, but i hoped for SU tools.. whatever. After a lot of research (and I feel I've become an expert on the subject by now!) this is what I've found: In 2018, the tzdata maintainers (IANA) corrected a historical mistake with the Europe/Dublin timezone. The mistake was rooted in a misunderstanding of whether IST meant "Irish Summer Time" or "Irish Standard Time". The problem was discussed at great length (http://mm.icann.org/pipermail/tz/2018-January/thread.html) and it was concluded that IST really meant Irish *Standard* Time (in constrast with, say, British *Summer* Time), and that this standard time is defined as UTC+0100. This corresponds to the article at https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland and the notes at https://en.wikipedia.org/wiki/Winter_time_(clock_lag); the source archive of tzdata has a long section dedicated to this problem and a large set of official references and links to www.irishstatutebook.ie. Once the question was settled, the only possible solution for keeping the Irish local time in sync with the rest of the world (for example, Belfast & London) was for IANA to _reverse_ the functioning of the DST flag for Ireland. The result is that in the current IANA timezone database (2021e), Europe/Dublin has DST applied in *winter*, with an adjustment of -1h (that is, negative). Digging deeper, one uncovers that there are a few other countries that have (or once had) the same time-switch mechanism as Ireland; amongst others, MenoData/Time4J#742 also concedes that negative DST is a reality. In s-nail, the logic that works out the UTC offset does the right thing in my testcase (october 2021, Ireland = UTC+0100), but then upon inspecting tm->tm_isdst it sees that DST is in effect (remember, flag has been reversed, so DST in Ireland is on in winter time) it adds one hour (it should subtract one, because the adjustment is negative). That's why I get a +0200 instead of +0000 out of s-nail. You may wonder why this problem hasn't been noticed by Irish people in the past three years (hey, there's quite an IT industry over here!). It turns out that the introduction of a negative DST adjustment caused all sorts of bugs back in 2018; in the source distribution of IANA's tzdata, one can spot this inside ./europe: # In January 2018 we discovered that the negative SAVE values in the # Eire rules cause problems with tests for ICU [...] and with tests # for OpenJDK [...] # To work around this problem, the build procedure can translate the # following data into two forms, one with negative SAVE values and the # other form with a traditional approximation for Irish timestamps # after 1971-10-31 02:00 UTC; although this approximation has tm_isdst # flags that are reversed, its UTC offsets are correct and this often # suffices. This source file currently uses only nonnegative SAVE # values, but this is intended to change and downstream code should # not rely on it. So, a temporary hack was put in place in order to allow distro maintainers to retain the old broken convention of IST and support buggy software, but it is clear that the current (and technically, and politically, correct) implementation of a negative DST adjustment for Ireland is there to stay. As a matter of fact, the distro maintainer can choose to compile tzdata to keep buggy software happy ("make DATAFORM=rearguard"), which replicates the behaviour of tzdata prior to 2018. Many distros seem to be doing that for one reason or another, while some have passed the upstream change down to their users (probably, without knowing). (also, remember that the IANA tz database is basically the only source of tz data and is used globally by pretty much anybody who has a system clock; I can see why embedded platforms may not be easy to patch to support the negative DST adjustment). This explains why I see this problem in Slackware, but not on, for example, CentOS (and also why some tools work correctly, and some, like s-nail in this case, does not). I am in the process of evaluating different approaches to solve this bug in a portable way (e.g. without relying on non-standard extensions like tm->tm_gmtoff, strftime's "%z" or timelocal()/gmtime()). He then also mentioned tm_gmtoff seems like the easiest way. If you're interested in portability, the only *portable* way of finding the offset from UTC that I've found is: struct tm l,g; g = *gmtime(&t); l = *localtime(&t); and work out the difference between g and l by checking the members (e.g. normalizing to either number of minutes) with something like: diff = (l->tm_sec-g->tm_sec)/60 +(l->tm_min-g->tm_min) +(l->tm_hour-g->tm_hour)*60 /* + compensate for day/month/year difference */ And that is an interesting approach that in one way or another other MUAs have gone. Do so, too! Many thanks for the effort, Andrea.
freebsd-git
pushed a commit
to freebsd/freebsd-ports
that referenced
this issue
Jan 27, 2022
Somewhere around 2018, the tzdata maintainers (IANA) corrected a historical mistake with the Europe/Dublin timezone. The mistake was rooted in a misunderstanding of whether IST meant "Irish Summer Time" or "Irish Standard Time". The problem was discussed at great length (http://mm.icann.org/pipermail/tz/2018-January/thread.html) and it was concluded that IST really meant Irish *Standard* Time (in constrast with, say, British *Summer* Time), and that this standard time is defined as UTC+0100. This corresponds to the article at https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland and the notes at https://en.wikipedia.org/wiki/Winter_time_(clock_lag); the source archive of tzdata has a long section dedicated to this problem and a large set of official references and links to www.irishstatutebook.ie. Once the question was settled, the only possible solution for keeping the Irish local time in sync with the rest of the world (timezones aside, the local time in Ireland - as understood by common people - is the same as in London and Belfast) was for IANA to _reverse_ the functioning of the DST flag for Ireland. The result is that in the current IANA timezone database (2021e), Europe/Dublin has DST applied in *winter*, with an adjustment of -1h (that is, negative). Digging deeper, one uncovers that there are a few other countries that have (or once had) the same time-switch mechanism as Ireland; amongst others, MenoData/Time4J#742 also concedes that negative DST is a reality. In heirloom mailx, the logic that works out the UTC offset does the right thing up to a point (November 2021, Ireland = UTC+0100), but then upon inspecting tm->tm_isdst it sees that DST is in effect (remember, flag has been reversed, so DST in Ireland is on in winter time) it adds one hour (it should subtract one, because the adjustment is negative, but mailx doesn't know). PR: 260137 Submitted by: Andrea Biardi <a.biardi@tiscali.it> Reported by: Andrea Biardi <a.biardi@tiscali.it> MFH: 2022Q1
freebsd-git
pushed a commit
to freebsd/freebsd-ports
that referenced
this issue
Jan 27, 2022
Somewhere around 2018, the tzdata maintainers (IANA) corrected a historical mistake with the Europe/Dublin timezone. The mistake was rooted in a misunderstanding of whether IST meant "Irish Summer Time" or "Irish Standard Time". The problem was discussed at great length (http://mm.icann.org/pipermail/tz/2018-January/thread.html) and it was concluded that IST really meant Irish *Standard* Time (in constrast with, say, British *Summer* Time), and that this standard time is defined as UTC+0100. This corresponds to the article at https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland and the notes at https://en.wikipedia.org/wiki/Winter_time_(clock_lag); the source archive of tzdata has a long section dedicated to this problem and a large set of official references and links to www.irishstatutebook.ie. Once the question was settled, the only possible solution for keeping the Irish local time in sync with the rest of the world (timezones aside, the local time in Ireland - as understood by common people - is the same as in London and Belfast) was for IANA to _reverse_ the functioning of the DST flag for Ireland. The result is that in the current IANA timezone database (2021e), Europe/Dublin has DST applied in *winter*, with an adjustment of -1h (that is, negative). Digging deeper, one uncovers that there are a few other countries that have (or once had) the same time-switch mechanism as Ireland; amongst others, MenoData/Time4J#742 also concedes that negative DST is a reality. In heirloom mailx, the logic that works out the UTC offset does the right thing up to a point (November 2021, Ireland = UTC+0100), but then upon inspecting tm->tm_isdst it sees that DST is in effect (remember, flag has been reversed, so DST in Ireland is on in winter time) it adds one hour (it should subtract one, because the adjustment is negative, but mailx doesn't know). PR: 260137 Submitted by: Andrea Biardi <a.biardi@tiscali.it> Reported by: Andrea Biardi <a.biardi@tiscali.it> MFH: 2022Q1 (cherry picked from commit c4f8092)
5u623l20
pushed a commit
to 5u623l20/freebsd-ports
that referenced
this issue
Jan 27, 2022
Somewhere around 2018, the tzdata maintainers (IANA) corrected a historical mistake with the Europe/Dublin timezone. The mistake was rooted in a misunderstanding of whether IST meant "Irish Summer Time" or "Irish Standard Time". The problem was discussed at great length (http://mm.icann.org/pipermail/tz/2018-January/thread.html) and it was concluded that IST really meant Irish *Standard* Time (in constrast with, say, British *Summer* Time), and that this standard time is defined as UTC+0100. This corresponds to the article at https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland and the notes at https://en.wikipedia.org/wiki/Winter_time_(clock_lag); the source archive of tzdata has a long section dedicated to this problem and a large set of official references and links to www.irishstatutebook.ie. Once the question was settled, the only possible solution for keeping the Irish local time in sync with the rest of the world (timezones aside, the local time in Ireland - as understood by common people - is the same as in London and Belfast) was for IANA to _reverse_ the functioning of the DST flag for Ireland. The result is that in the current IANA timezone database (2021e), Europe/Dublin has DST applied in *winter*, with an adjustment of -1h (that is, negative). Digging deeper, one uncovers that there are a few other countries that have (or once had) the same time-switch mechanism as Ireland; amongst others, MenoData/Time4J#742 also concedes that negative DST is a reality. In heirloom mailx, the logic that works out the UTC offset does the right thing up to a point (November 2021, Ireland = UTC+0100), but then upon inspecting tm->tm_isdst it sees that DST is in effect (remember, flag has been reversed, so DST in Ireland is on in winter time) it adds one hour (it should subtract one, because the adjustment is negative, but mailx doesn't know). PR: 260137 Submitted by: Andrea Biardi <a.biardi@tiscali.it> Reported by: Andrea Biardi <a.biardi@tiscali.it> MFH: 2022Q1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While the last issue #735 has ensured that newest tz-distributions v2018a and v2018b are compilable, the topic is still how to interprete such negative offsets and their counter-parts in summer (when zero offset indicates standard time).
Actually the API of Time4J (javadoc) is still designed/named to consider dst only as positive and leaves open how to interprete negative dst. Maybe the term "daylight-saving" is no longer appropriate in the API and should be deprecated and replaced by the term "extra-time" or "extra-offset". This affects the classes
Timezone,ZonalTransitionandNameStyle. An alternative method calledisStandardTime(...)might replace actual methods likeisDaylightSaving(...)(with reverse meaning).Obviously, the TZDB-maintainers will only temporarily roll back the negative dst offsets in next version 2018c but go back to negative dst in foreseeable future. It is completely unclear yet if ICU4J / CLDR / OpenJDK will prepare a fix or not then. And if not then the question arises how Time4J will bridge/solve the conflict between both sides.
For more info about negative dst see also: https://en.wikipedia.org/wiki/Winter_time_(clock_lag)
The text was updated successfully, but these errors were encountered: