Re: [tz] [tz-announce] 2018f release of tz code and data available
On 10/18/18 8:14 AM, Christos Zoulas wrote:
My folks are reporting that java does not like it:
ERROR: Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - SepSat>=8 25:00 0 S' ERROR: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Thanks for the heads-up; please try the attached patch. Is there some way your folks can try the development version on GitHub every now and then? That "25:00" has been in the development version since last month and was explicitly called out when the patch was circulated on the mailing list <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd have been nice to catch the glitch before 2018f came out.
On Oct 18, 11:14am, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: [tz] [tz-announce] 2018f release of tz code and data availabl | Thanks for the heads-up; please try the attached patch. | | Is there some way your folks can try the development version on GitHub | every now and then? That "25:00" has been in the development version | since last month and was explicitly called out when the patch was | circulated on the mailing list | <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd | have been nice to catch the glitch before 2018f came out. Will ask them to test more frequently. I will also test the patch and report back. Best, christos | | --------------C534FB3F9037DCEF3FDD7B61 | Content-Type: text/x-patch; | name="0001-Avoid-25-00-in-rearguard-format.patch" | Content-Transfer-Encoding: 7bit | Content-Disposition: attachment; | filename="0001-Avoid-25-00-in-rearguard-format.patch" | | >From 401c42d991d4277cd606933fc9f5d9a13d1ac228 Mon Sep 17 00:00:00 2001 | From: Paul Eggert <eggert@cs.ucla.edu> | Date: Thu, 18 Oct 2018 11:06:07 -0700 | Subject: [PROPOSED] Avoid 25:00 in rearguard format | | (Problem reported by Christos Zoulas.) | * NEWS: Mention this. | * ziguard.awk: Change "Rule ... Sat>=8 25:00" to "Rule ... Sun>=9 1:00". | --- | NEWS | 11 +++++++++++ | ziguard.awk | 7 +++++++ | 2 files changed, 18 insertions(+) | | diff --git a/NEWS b/NEWS | index aeeef10..16f0947 100644 | --- a/NEWS | +++ b/NEWS | @@ -1,5 +1,16 @@ | News for the tz database | | +Unreleased, experimental changes | + | + Changes to code | + | + The translator to rearguard format now rewrites the line | + "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to | + "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S". | + This caters to zic before 2007 and to at least one Java-based zi | + compiler of uncertain vintage. (Reported by Christos Zoulas.) | + | + | Release 2018f - 2018-10-18 00:14:18 -0700 | | Briefly: | diff --git a/ziguard.awk b/ziguard.awk | index 42e2910..e3c7298 100644 | --- a/ziguard.awk | +++ b/ziguard.awk | @@ -80,6 +80,13 @@ DATAFORM != "main" { | if (comment_out) { | sub(/^/, "#") | } | + | + # In rearguard format, change the Japan rule line with "Sat>=8 25:00" | + # to "Sun>=9 1:00", to cater to zic before 2007 and to older Java. | + if (!vanguard && $1 == "Rule" && $7 == "Sat>=8" && $8 == "25:00") { | + sub(/Sat>=8/, "Sun>=9") | + sub(/25:00/, " 1:00") | + } | } | | # If a Link line is followed by a Zone line for the same data, comment | -- | 2.17.2 | | | --------------C534FB3F9037DCEF3FDD7B61-- -- End of excerpt from Paul Eggert
The tzupdater used was the latest one downloaded from Oracle's site (2.2.0). I modified the asia file to have this line: Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S I was able to succesfully patch JDKs 1.8.0.181, 10.0.2, 11-28. Though I'm not exactly sure how I would verify that the change is actually correct. On 10/18/18 14:48, Christos Zoulas wrote:
On Oct 18, 11:14am, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: [tz] [tz-announce] 2018f release of tz code and data availabl
| Thanks for the heads-up; please try the attached patch. | | Is there some way your folks can try the development version on GitHub | every now and then? That "25:00" has been in the development version | since last month and was explicitly called out when the patch was | circulated on the mailing list | <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd | have been nice to catch the glitch before 2018f came out.
Will ask them to test more frequently. I will also test the patch and report back.
Best,
christos
| | --------------C534FB3F9037DCEF3FDD7B61 | Content-Type: text/x-patch; | name="0001-Avoid-25-00-in-rearguard-format.patch" | Content-Transfer-Encoding: 7bit | Content-Disposition: attachment; | filename="0001-Avoid-25-00-in-rearguard-format.patch" | | >From 401c42d991d4277cd606933fc9f5d9a13d1ac228 Mon Sep 17 00:00:00 2001 | From: Paul Eggert <eggert@cs.ucla.edu> | Date: Thu, 18 Oct 2018 11:06:07 -0700 | Subject: [PROPOSED] Avoid 25:00 in rearguard format | | (Problem reported by Christos Zoulas.) | * NEWS: Mention this. | * ziguard.awk: Change "Rule ... Sat>=8 25:00" to "Rule ... Sun>=9 1:00". | --- | NEWS | 11 +++++++++++ | ziguard.awk | 7 +++++++ | 2 files changed, 18 insertions(+) | | diff --git a/NEWS b/NEWS | index aeeef10..16f0947 100644 | --- a/NEWS | +++ b/NEWS | @@ -1,5 +1,16 @@ | News for the tz database | | +Unreleased, experimental changes | + | + Changes to code | + | + The translator to rearguard format now rewrites the line | + "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to | + "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S". | + This caters to zic before 2007 and to at least one Java-based zi | + compiler of uncertain vintage. (Reported by Christos Zoulas.) | + | + | Release 2018f - 2018-10-18 00:14:18 -0700 | | Briefly: | diff --git a/ziguard.awk b/ziguard.awk | index 42e2910..e3c7298 100644 | --- a/ziguard.awk | +++ b/ziguard.awk | @@ -80,6 +80,13 @@ DATAFORM != "main" { | if (comment_out) { | sub(/^/, "#") | } | + | + # In rearguard format, change the Japan rule line with "Sat>=8 25:00" | + # to "Sun>=9 1:00", to cater to zic before 2007 and to older Java. | + if (!vanguard && $1 == "Rule" && $7 == "Sat>=8" && $8 == "25:00") { | + sub(/Sat>=8/, "Sun>=9") | + sub(/25:00/, " 1:00") | + } | } | | # If a Link line is followed by a Zone line for the same data, comment | -- | 2.17.2 | | | --------------C534FB3F9037DCEF3FDD7B61-- -- End of excerpt from Paul Eggert
Hamilton Slye wrote:
I'm not exactly sure how I would verify that the change is actually correct.
In the full tzdb distribution you can run the command 'make check_tzs' to check whether your change to the source does not affect the behavior of the resulting binary files. I regularly do that for patches like the patch I proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html>.
Paul, I was out of the office for a week and a half and so I wasn't able to get back to it until today. I tried using 2018g and it still has the problem with tzupdater. I am able to get it to work if I change the particular Japan rule in the asia file to be: Rule Japan 1948 1951 - Sep Sun>=9 01:00 0 S I have not downloaded the source and built it locally, I manually edited the data file. So my statement about testing was really about how to test that Java has interpreted it correctly. On 10/20/18 11:33, Paul Eggert wrote:
Hamilton Slye wrote:
I'm not exactly sure how I would verify that the change is actually correct.
In the full tzdb distribution you can run the command 'make check_tzs' to check whether your change to the source does not affect the behavior of the resulting binary files. I regularly do that for patches like the patch I proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html>.
On 11/2/18 11:09 AM, Hamilton Slye wrote:
I tried using 2018g and it still has the problem with tzupdater.
That is expected if you used the main-format tarball. Did you try the rearguard-format tarball? Please see the "PS" at the end of the 2018g announcement <https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html> which references the rearguard-format tarball <https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.g...> and its checksums. If it doesn't work, please let us know the symptoms.
Ah. I did not look at the official announcement... Christos told us it was available so I went to the IANA web site to grab it... The rearguard tarball works. Thanks! On 11/02/18 14:14, Paul Eggert wrote:
On 11/2/18 11:09 AM, Hamilton Slye wrote:
I tried using 2018g and it still has the problem with tzupdater.
That is expected if you used the main-format tarball. Did you try the rearguard-format tarball? Please see the "PS" at the end of the 2018g announcement <https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html> which references the rearguard-format tarball <https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.g...> and its checksums. If it doesn't work, please let us know the symptoms.
Thanks for the report. Tracked via https://bugs.openjdk.java.net/browse/JDK-8212684 on the JDK end. Regards, Sean. On 18/10/18 19:14, Paul Eggert wrote:
On 10/18/18 8:14 AM, Christos Zoulas wrote:
My folks are reporting that java does not like it:
ERROR: Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - SepSat>=8 25:00 0 S' ERROR: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Thanks for the heads-up; please try the attached patch.
Is there some way your folks can try the development version on GitHub every now and then? That "25:00" has been in the development version since last month and was explicitly called out when the patch was circulated on the mailing list <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd have been nice to catch the glitch before 2018f came out.
The java.time.* code exposes the local time that the transition occurs. This can be represented within the bounds 00:00 to 24:00. There is no way to represent 25:00 or negatives. https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneOffsetTransitio... As such, the tzdb parser would have to convert 25:00 and try to reinterpret it as the next day within the valid bounds, which is far from ideal. It would be much better for the upstream source to represent the data in a more standard and backwards compatible way. (The existing API will be supported unaltered for many years, potentially decades, so changing the API is not a viable solution.) Stephen On Thu, 18 Oct 2018, 19:15 Paul Eggert, <eggert@cs.ucla.edu> wrote:
On 10/18/18 8:14 AM, Christos Zoulas wrote:
My folks are reporting that java does not like it:
ERROR: Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - SepSat>=8 25:00 0 S' ERROR: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Thanks for the heads-up; please try the attached patch.
Is there some way your folks can try the development version on GitHub every now and then? That "25:00" has been in the development version since last month and was explicitly called out when the patch was circulated on the mailing list <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd have been nice to catch the glitch before 2018f came out.
Stephen Colebourne wrote:
It would be much better for the upstream source to represent the data in a more standard and backwards compatible way.
The original Japanese regulation does seem to say that the transition occurs Saturday at 25:00 (as this is how such times are often expressed in Japan), and it's better to represent data as close to the original as the format allows. This is not a recent change to the format, which was relaxed to allow 25:00 (and other out-of-range times) in 2007, as first proposed here: https://mm.icann.org/pipermail/tz/2007-May/014341.html with no disagreement at the time.
(The existing API will be supported unaltered for many years, potentially decades, so changing the API is not a viable solution.)
This sort of compatibility issue is what rearguard format is for, and the patch proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html> should suffice for the existing Java API, which as I understand it needs to use rearguard format anyway. Success for this approach with OpenJDK has been reported in <https://bugs.openjdk.java.net/browse/JDK-8212684>. When someone has the time, though, the Java API should get fixed, as insisting on times in the range 00:00-24:00 prohibits useful and practical rules. It's not just Japan; it's also rules like "22:00 on the day before the last Sunday in March" that are quite plausible in real-world practice.
* Paul Eggert:
Stephen Colebourne wrote:
It would be much better for the upstream source to represent the data in a more standard and backwards compatible way.
The original Japanese regulation does seem to say that the transition occurs Saturday at 25:00 (as this is how such times are often expressed in Japan), and it's better to represent data as close to the original as the format allows. This is not a recent change to the format, which was relaxed to allow 25:00 (and other out-of-range times) in 2007, as first proposed here:
https://mm.icann.org/pipermail/tz/2007-May/014341.html
with no disagreement at the time.
What's the exact algorithm for normalizing the date? Is there only one possible way of doing this? Thanks, Florian
On Oct 22, 2018, at 1:56 PM, Florian Weimer <fweimer@redhat.com> wrote:
[EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information.
* Paul Eggert:
Stephen Colebourne wrote:
It would be much better for the upstream source to represent the data in a more standard and backwards compatible way.
The original Japanese regulation does seem to say that the transition occurs Saturday at 25:00 (as this is how such times are often expressed in Japan), and it's better to represent data as close to the original as the format allows. This is not a recent change to the format, which was relaxed to allow 25:00 (and other out-of-range times) in 2007, as first proposed here:
https://mm.icann.org/pipermail/tz/2007-May/014341.html
with no disagreement at the time.
What's the exact algorithm for normalizing the date? Is there only one possible way of doing this?
It seems reasonably obvious and unambiguous, but perhaps it's worth a few lines in the theory file. Hours are simply offsets from midnight of the stated day, so 25:00 means plus one day plus one hour. Similarly, days of the month are offsets from the start of the month (one-based), so January 0 is the beginning of the day one day before the start of January. (That notation appears in the definition of the second, two or three definitions ago.) paul
On 10/22/18 10:56 AM, Florian Weimer wrote:
What's the exact algorithm for normalizing the date? Is there only one possible way of doing this?
Times past 24:00 are treated like times before 24:00, that is, HH:MM is considered to be HH hours and MM minutes after the start of the calendar day (or before the start if there is a leading '-'). As with all HH:MM timestamps, leap seconds are ignored in this calculation. It would not be useful to count leap seconds as they are typically ignored in civil-time rules. The question of leap seconds came up recently in another thread <https://mm.icann.org/pipermail/tz/2018-October/027045.html> so I am attaching a proposed patch to try to clarify confusion in this area. Are there other possible ways of doing normalization? If so, please let me know, as we should nail down the spec to avoid any other confusion in this area.
* Paul Eggert:
On 10/22/18 10:56 AM, Florian Weimer wrote:
What's the exact algorithm for normalizing the date? Is there only one possible way of doing this?
Times past 24:00 are treated like times before 24:00, that is, HH:MM is considered to be HH hours and MM minutes after the start of the calendar day (or before the start if there is a leading '-').
As with all HH:MM timestamps, leap seconds are ignored in this calculation. It would not be useful to count leap seconds as they are typically ignored in civil-time rules. The question of leap seconds came up recently in another thread <https://mm.icann.org/pipermail/tz/2018-October/027045.html> so I am attaching a proposed patch to try to clarify confusion in this area.
Are there other possible ways of doing normalization? If so, please let me know, as we should nail down the spec to avoid any other confusion in this area.
I mainly meant how to adjust the transition rules to get a proper POSIX rule. Is this always possible? Thanks, Florian
On 10/22/18 11:22 PM, Florian Weimer wrote:
I mainly meant how to adjust the transition rules to get a proper POSIX rule. Is this always possible?
No, because POSIX does not allow settings like TZ='GST3GDT,M3.5.0/-2,M10.5.0/-1', where the '-2' is short for '-02:00' and means that in spring the transition is at 22:00 on the day before the last Sunday in March. There is no POSIX-conforming equivalent to this. We should fix POSIX to allow times outside the 00:00-24:00 range, since they are used in practice. Glibc supports them, and other POSIX-compatible implementations do too. For example, run the command 'tail -n1 /usr/share/zoneinfo/America/Godthab' on a Red Hat platform.
I'm willing to argue for a change to the Java API as there are definitely rules that can't be expressed in any other way except via out of bounds times. However, there is no particular reason for this particular rule to be expressed as out of bounds 25:00. In addition to Java itself, there are a number of other Java libraries impacted by this. As I've pointed out before, the rearguard approach does not really help because it is not a distributed set of source files - it requires pre-processing. Since there is no difference to the output timestamps, and no particular reason to express the rule as 25:00, can we agree to revert the main source file to use 01:00 until release 2020a to give time for the change to percolate through the libraries? thanks Stephen On Sun, 21 Oct 2018 at 00:43, Paul Eggert <eggert@cs.ucla.edu> wrote:
Stephen Colebourne wrote:
It would be much better for the upstream source to represent the data in a more standard and backwards compatible way.
The original Japanese regulation does seem to say that the transition occurs Saturday at 25:00 (as this is how such times are often expressed in Japan), and it's better to represent data as close to the original as the format allows. This is not a recent change to the format, which was relaxed to allow 25:00 (and other out-of-range times) in 2007, as first proposed here:
https://mm.icann.org/pipermail/tz/2007-May/014341.html
with no disagreement at the time.
(The existing API will be supported unaltered for many years, potentially decades, so changing the API is not a viable solution.)
This sort of compatibility issue is what rearguard format is for, and the patch proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html> should suffice for the existing Java API, which as I understand it needs to use rearguard format anyway. Success for this approach with OpenJDK has been reported in <https://bugs.openjdk.java.net/browse/JDK-8212684>.
When someone has the time, though, the Java API should get fixed, as insisting on times in the range 00:00-24:00 prohibits useful and practical rules. It's not just Japan; it's also rules like "22:00 on the day before the last Sunday in March" that are quite plausible in real-world practice.
On 10/22/18 2:59 PM, Stephen Colebourne wrote:
the rearguard approach does not really help because it is not a distributed set of source files - it requires pre-processing.
I can continue to distribute the rearguard format in source form until 2020 rolls around; that should suffice for Java, no?
What I'm looking for is to have the file tzdata-2018g.tar.gz contain the rule in the 01:00 form until 2020a. ie. not commented out or requiring code to generate it. AFAICT, the rearguard source files are not distributed. Neither tzdata-2018f.tar.gz nor tzdb-2018f.tar.lz contain the rearguard form of the source files. Stephen On Tue, 23 Oct 2018 at 00:09, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/22/18 2:59 PM, Stephen Colebourne wrote:
the rearguard approach does not really help because it is not a distributed set of source files - it requires pre-processing.
I can continue to distribute the rearguard format in source form until 2020 rolls around; that should suffice for Java, no?
On 10/23/18 2:38 AM, Stephen Colebourne wrote:
AFAICT, the rearguard source files are not distributed.
They are distributed in a different location; see the "PS" section in the most recent announcement. They are in source (zic input) form, generated automatically from the hand-maintained main source.
On Tue, 23 Oct 2018 at 17:38, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/23/18 2:38 AM, Stephen Colebourne wrote:
AFAICT, the rearguard source files are not distributed.
They are distributed in a different location; see the "PS" section in the most recent announcement. They are in source (zic input) form, generated automatically from the hand-maintained main source.
Great, But as I indicated earlier (and as per another recent thread), what the Java world really needs is for a 2018g to be released that uses 01:00 instead of 25:00 in the main format (not rearguard). Give it 15 months and I'd expect the issue will have worked through the various processes, but the JDK in particular is not always fast to change [1] Stephen [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056167.htm...
On 10/23/18 1:39 PM, Stephen Colebourne wrote:
Great, But as I indicated earlier (and as per another recent thread), what the Java world really needs is for a 2018g to be released that uses 01:00 instead of 25:00 in the main format (not rearguard).
Sorry, I'm not understanding the distinction. A rearguard tarball contains .zi files, and Oracle's Java-based tools accept .zi files. Why don't these tools accept the .zi files in a rearguard tarball? In other words, goes wrong if you try to use a rearguard tarball with Oracle's Java-based tools?
On Tue, 23 Oct 2018 at 22:32, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/23/18 1:39 PM, Stephen Colebourne wrote:
Great, But as I indicated earlier (and as per another recent thread), what the Java world really needs is for a 2018g to be released that uses 01:00 instead of 25:00 in the main format (not rearguard).
Sorry, I'm not understanding the distinction. A rearguard tarball contains .zi files, and Oracle's Java-based tools accept .zi files. Why don't these tools accept the .zi files in a rearguard tarball? In other words, goes wrong if you try to use a rearguard tarball with Oracle's Java-based tools?
The issue is that virtually no-one knows about those additional distributions. I didn't and I follow the list! Oracle's tzupdater is not the only tool in the world of Java that uses these files and not the only one broken. Bear in mind that users download tzdb data files directly, so trying to teach them to find a different, hidden, distribution isn't a great idea. I really don't think my request to revert the main file for 15 months is unreasonable. Stephen
On 10/24/18 5:16 AM, Stephen Colebourne wrote:
The issue is that virtually no-one knows about those additional distributions.
That issue will always be with us; it won't be any different in 2019 or 2020 than it is now. And we had the same issue in 2011 when we made the transition from elsie.nci.nih.gov and changed distribution URLs. Java users did OK back then, and I don't see why we need to do this transition differently. The underlying problem here is that Java-based .zi parsers and operational procedures are too tightly coupled to tzdb format details that the Java parsers support only imperfectly or with a long lag time, and this problem will continue as long as tzdb evolves (which it will). A good way to address the problem is for Java to do what every other significant downstream distribution does, which is to redistribute the data the way Java wants it, thus decoupling the tzdb distribution from the Java distribution. There will be glitches when this decoupling is accomplished, regardless of whether it's done in the next tzdb release or a dozen tzdb releases from now, and we might as well get started now.
Just my two cents.. I needed to patch up our JDKs since we need the Volgograd-patch and can't wait for an official release. That meant me hitting the same problem as described in https://bugs.openjdk.java.net/browse/JDK-8212684 and having to build the rearguard from the tz-source myself. Would it be possible to host these *guard-builds on the iana.org/time-zones page as well, giving downstream users that will have to rely on these releases for some time a place to find them without building them from source? Apart from saving us a build it also gives people who are not following the tz-code closely a notice that something has changed and that they need to watch out for this. Thanks. //Per Kristian On 25. okt. 2018 10:40, Paul Eggert wrote:
On 10/24/18 5:16 AM, Stephen Colebourne wrote:
The issue is that virtually no-one knows about those additional distributions.
That issue will always be with us; it won't be any different in 2019 or 2020 than it is now. And we had the same issue in 2011 when we made the transition from elsie.nci.nih.gov and changed distribution URLs. Java users did OK back then, and I don't see why we need to do this transition differently.
The underlying problem here is that Java-based .zi parsers and operational procedures are too tightly coupled to tzdb format details that the Java parsers support only imperfectly or with a long lag time, and this problem will continue as long as tzdb evolves (which it will). A good way to address the problem is for Java to do what every other significant downstream distribution does, which is to redistribute the data the way Java wants it, thus decoupling the tzdb distribution from the Java distribution. There will be glitches when this decoupling is accomplished, regardless of whether it's done in the next tzdb release or a dozen tzdb releases from now, and we might as well get started now.
Date: Thu, 25 Oct 2018 10:59:20 +0200 From: Per Kristian Fjellby <p.fjellby@sportradar.com> Message-ID: <297b728a-12df-0b9f-de52-da5e44c66dc6@sportradar.com> | Would it be possible to host these *guard-builds on the iana.org/time-zones page This is all going way to far. Why would it be useful to have the data on any IANA page? IANA isn't resourced to be a supply source for data to be routinely fetched by end users - if java (or any other distribution) needs to distribute time zone data to their users (and don't we all) they are responsible for housing a copy of that data, and making it available to their users (the same way as all other updates, options, and whatever...) Aside from not imposing extra load on the IANA system, this also has the advantage that any distribution can distribute the data in whatever form is best for them - if 25::00 doesn't work, change it. Stop abusing the system. kre
The difference between 25:00 abd 01:00 is that, assuming the DST transition take place at September 6 of certain year, then the last hour with DST active would be considered as part of September 6 if 01:00 approach is used, while it should be September 5 going to 25:00. 2018-10-23 06:00, Stephen Colebourne <jodastephen@gmail.com> wrote:
I'm willing to argue for a change to the Java API as there are definitely rules that can't be expressed in any other way except via out of bounds times.
However, there is no particular reason for this particular rule to be expressed as out of bounds 25:00. In addition to Java itself, there are a number of other Java libraries impacted by this. As I've pointed out before, the rearguard approach does not really help because it is not a distributed set of source files - it requires pre-processing.
Since there is no difference to the output timestamps, and no particular reason to express the rule as 25:00, can we agree to revert the main source file to use 01:00 until release 2020a to give time for the change to percolate through the libraries?
thanks Stephen
On Sun, 21 Oct 2018 at 00:43, Paul Eggert <eggert@cs.ucla.edu> wrote:
Stephen Colebourne wrote:
It would be much better for the upstream source to represent the data
in a
more standard and backwards compatible way.
The original Japanese regulation does seem to say that the transition occurs Saturday at 25:00 (as this is how such times are often expressed in Japan), and it's better to represent data as close to the original as the format allows. This is not a recent change to the format, which was relaxed to allow 25:00 (and other out-of-range times) in 2007, as first proposed here:
https://mm.icann.org/pipermail/tz/2007-May/014341.html
with no disagreement at the time.
(The existing API will be supported unaltered for many years, potentially decades, so changing the API is not a viable solution.)
This sort of compatibility issue is what rearguard format is for, and the patch proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html> should suffice for the existing Java API, which as I understand it needs to use rearguard format anyway. Success for this approach with OpenJDK has been reported in <https://bugs.openjdk.java.net/browse/JDK-8212684>.
When someone has the time, though, the Java API should get fixed, as insisting on times in the range 00:00-24:00 prohibits useful and practical rules. It's not just Japan; it's also rules like "22:00 on the day before the last Sunday in March" that are quite plausible in real-world practice.
On Sat 2018-10-20T21:55:50+0100 Stephen Colebourne hath writ:
The java.time.* code exposes the local time that the transition occurs. This can be represented within the bounds 00:00 to 24:00. There is no way to represent 25:00 or negatives. https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneOffsetTransitio...
Many examples of non-normalized dates and times exist in historical literature. One example is 1970 January -1 and December 35 at https://babel.hathitrust.org/cgi/pt?id=mdp.39015017143895;view=1up;seq=30 The subsequent page has January -6 and December 40, and not to be forgotten in other civil use was 1712 February 30 https://en.wikipedia.org/wiki/February_30
As such, the tzdb parser would have to convert 25:00 and try to reinterpret it as the next day within the valid bounds, which is far from ideal. It would be much better for the upstream source to represent the data in a more standard and backwards compatible way.
People did these sorts of things, and not just in astronomy. The choice is whether or not a modern parser will be able to read what people actually did or go into a mode resembling denial. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Steve Allen said:
Many examples of non-normalized dates and times exist in historical literature. [...] and not to be forgotten in other civil use was 1712 February 30 https://en.wikipedia.org/wiki/February_30
Um, that one *is* normalized: it was a separate day between February 29th and March 1st. Non-normalized is when the surgeon wrote "29th February 2013" on my surgery consent form. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Sun, 21 Oct 2018 at 12:51, Clive D.W. Feather <clive@davros.org> wrote:
and not to be forgotten in other civil use was 1712 February 30 https://en.wikipedia.org/wiki/February_30
Um, that one *is* normalized: it was a separate day between February 29th and March 1st.
Except when we're speaking of normalization, we're typically referring to the proleptic Gregorian calendar, so that would have just been 1712 March 11, as that particular Friday was observed in Italy. In Britain and her colonies, which still used the Julian calendar at the time but hadn't made the same omissions as Sweden in 1704 and 1708, that Friday was simply 1712 February 29, and Sweden, with its step back, could move forward alongside them on the following day, March 1. * * * Unrelated, but the year calendar views on timeanddate.com (note the different country settings) properly display the weirder months… https://www.timeanddate.com/calendar/?year=1712&country=21 (Sweden has 1712 February 30 to resync with Julian calendar) https://www.timeanddate.com/calendar/?year=1753&country=21 (Sweden adopts Gregorian calendar by skipping 1753 February 18–28, inclusive) https://www.timeanddate.com/calendar/?year=1752&country=9 (Britain adopts Gregorian calendar by skipping 1752 September 3–13, inclusive) …but, interestingly, it appears the month views only handle the cases where the month is shorter than usual, not longer: https://www.timeanddate.com/calendar/custom.html?year=1712&month=2&country=2... (doesn't show Sweden's 1712 February 30) https://www.timeanddate.com/calendar/custom.html?year=1712&month=3&country=2... (properly displays Sweden's 1712 March starting on Saturday, despite the above) https://www.timeanddate.com/calendar/custom.html?year=1753&month=2&country=2... (properly displays Sweden's short 1753 February) https://www.timeanddate.com/calendar/custom.html?year=1752&month=9&country=9... (properly displays Britain's short 1752 September) -- Tim Parenti
On 2018-10-21 03:00, Steve Allen wrote:
Many examples of non-normalized dates and times exist in historical literature.
For time stamps of UTC, or of a time scale derived from UTC with a piecewise constant offset (as for civil time scales), time-of-day values on or after 24 hours may be ambiguous due to leap seconds. The fictitious UTC time stamp "2016-12-31T25Z" could indeed be taken to mean 2016-12-31T00Z + 25 h = 2017-01-01T00:59:59Z or else 2017-01-01T00Z + 01 h = 2017-01-01T00:00:00Z. That is probably one reason why the draft new version of ISO 8601 proposes to drop even the notation for the time of day 24 h after midnight (does "2016-12-31T24Z" mean 2016-12-31T23:59:60Z or 2017-01-01T00:00:00Z?). It is true that this ambiguity can arise at most for two (or twelve) dates in a year, but a parser for zic input has to deal with all cases, and cannot be written correctly unless the notation is defined unambiguously. There is no such ambiguity with day of the month numbers less than 01 or > ultimo, so that it is always possible to avoid any time-of-day values below 00 h or on or after 24 h in time stamps of UTC or of civil times. Michael Deckers.
I can't see the problem here. For instance, Japan is now using UTC+9, so the leap second take place right before 9am(00:00:00Z), yet 10am that day would still unambiguously mean 10am(01:00:00Z). I cannot see why it would be a problem for UTC after 24z. 2018-10-22 05:25, Michael H Deckers via tz <tz@iana.org> wrote:
On 2018-10-21 03:00, Steve Allen wrote:
Many examples of non-normalized dates and times exist in historical literature.
For time stamps of UTC, or of a time scale derived from UTC with a piecewise constant offset (as for civil time scales), time-of-day values on or after 24 hours may be ambiguous due to leap seconds.
The fictitious UTC time stamp "2016-12-31T25Z" could indeed be taken to mean 2016-12-31T00Z + 25 h = 2017-01-01T00:59:59Z or else 2017-01-01T00Z + 01 h = 2017-01-01T00:00:00Z. That is probably one reason why the draft new version of ISO 8601 proposes to drop even the notation for the time of day 24 h after midnight (does "2016-12-31T24Z" mean 2016-12-31T23:59:60Z or 2017-01-01T00:00:00Z?).
It is true that this ambiguity can arise at most for two (or twelve) dates in a year, but a parser for zic input has to deal with all cases, and cannot be written correctly unless the notation is defined unambiguously.
There is no such ambiguity with day of the month numbers less than 01 or > ultimo, so that it is always possible to avoid any time-of-day values below 00 h or on or after 24 h in time stamps of UTC or of civil times.
Michael Deckers.
Michael H Deckers via tz wrote:
time-of-day values on or after 24 hours may be ambiguous due to leap seconds.
Only if we decide they're ambiguous. Instead, let's resolve the ambiguity in the obvious and useful way.
The fictitious UTC time stamp "2016-12-31T25Z" could indeed be taken to mean 2016-12-31T00Z + 25 h = 2017-01-01T00:59:59Z or else 2017-01-01T00Z + 01 h = 2017-01-01T00:00:00Z.
Only the latter meaning is useful in tzdb, so let's do it that way. We went through this issue a while ago with "rolling" versus "stationary" leap seconds, only one of which is useful in practice, and in hindsight we should have supported only the useful variant.
participants (14)
-
christos＠zoulas.com -
Clive D.W. Feather -
Florian Weimer -
Hamilton Slye -
Michael H Deckers -
Paul Eggert -
Paul.Koning＠dell.com -
Per Kristian Fjellby -
Phake Nick -
Robert Elz -
Seán Coffey -
Stephen Colebourne -
Steve Allen -
Tim Parenti