Hi Masanori,
Thank you for looking at the issue and your contribution. I am also
investigating it (as an assignee of the bug), and looking at this old
issue:
https://bugs.openjdk.java.net/browse/JDK-4177484
The comment suggests that the existing behavior is the expected one. In
fact, your fix would break some regression test cases in
jdk/java/util/Calendar/CalendarRegression.java.
I will need some more archaeological investigation, but I am inclined to
close it as not an issue at the moment.
Naoto
On 9/12/19 12:16 AM, Yano, Masanori wrote:
Hello.
I think JDK-8229471 occurs because a change of TimeZone is not considered in
getTime().
To resolve this problem, isTimeSet flag must be set to false when setTimeZone()
is called.
Please review the following change.
diff -r e1269de19aa5 src/java.base/share/classes/java/util/Calendar.java
--- a/src/java.base/share/classes/java/util/Calendar.java Thu Aug 22
14:09:36 2019 -0700
+++ b/src/java.base/share/classes/java/util/Calendar.java Thu Sep 12
11:45:37 2019 +0900
@@ -2901,7 +2901,7 @@
* generally, a call to setTimeZone() affects calls to set() BEFORE
AND
* AFTER it up to the next call to complete().
*/
- areAllFieldsSet = areFieldsSet = false;
+ isTimeSet = areAllFieldsSet = areFieldsSet = false;
}
/**
diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/test/jdk/java/util/Calendar/Bug8229471.java Thu Sep 12 11:45:37 2019
+0900
@@ -0,0 +1,22 @@
+/*
+ *@test
+ *@bug 8229471
+ *@summary test for recompute when Calendar.setTimeZone()
+ */
+
+import java.util.Calendar;
+import java.util.Date;
+import java.util.Locale;
+import java.util.TimeZone;
+
+public class Bug8229471 {
+ public static void main(String[] args) throws Exception {
+ Calendar calendar = Calendar.getInstance(new Locale("en", "US"));
+ Date date1 = calendar.getTime();
+ calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest"));
+ Date date2 = calendar.getTime();
+ if (date1.equals(date2)) {
+ throw new RuntimeException("Bug8229471: failed. TimeZone is not
applied.");
+ }
+ }
+}
Regards,
Masanori Yano
