JDK-8066652 : Default TimeZone is GMT not local if user.timezone is invalid on Mac OS
- Type: Bug
- Component: core-libs
- Sub-Component: java.util:i18n
- Affected Version: 7u60,7u72,8u25
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: os_x
- CPU: x86
- Submitted: 2014-12-02
- Updated: 2021-11-05
- Resolved: 2016-08-01
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 8 | JDK 9 | Other |
|---|---|---|
8u251Fixed  |
9 b130Fixed |
openjdk8u322Fixed |
Related Reports
|
Relates :
|
Description
FULL PRODUCT VERSION :
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Darwin My-MacBook-Pro.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
EXTRA RELEVANT SYSTEM CONFIGURATION :
Timezone is America/New_York
A DESCRIPTION OF THE PROBLEM :
When the system property user.timezone is set to an invalid timezone (e.g. "foo/bar"), the timezone returned by TimeZone.getDefault() is always GMT. The timezone has the correct default when user.timezone is not set. After getting the default timezone, the user.timezone property is set to "GMT}05:00" where } is an unprintable character. This also affects creating a new Date object.
I don't know where to put it, but, if you look at:
http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/5cca2f1a37da/src/solaris/native/java/util/TimeZone_md.c#l690
and:
http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/5cca2f1a37da/src/solaris/native/java/util/TimeZone_md.c#l693
It sets a char to a string literal. This does not exist in the jdk7 source. It does exist in jdk8 and jdk8u
ADDITIONAL REGRESSION INFORMATION:
This commit introduced the bug to jdk7u: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/5cca2f1a37da
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached code with:
java -Duser.timezone=foo/bar JavaTest
The expected behavior was calculated by running:
java -Duser.timezone=GMT-05:00 JavaTest
Note: in iTerm2 the } in the actual result renders as �
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
u.t: GMT-05:00
a date: Tue Dec 02 13:31:19 GMT-05:00 2014
timezone: sun.util.calendar.ZoneInfo[id="GMT-05:00",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
u.t: GMT-05:00
ACTUAL -
u.t: foo/bar
a date: Tue Dec 02 18:15:11 GMT 2014
timezone: sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
u.t: GMT}05:00
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.*;
public class JavaTest {
public static void main(String[] args) throws Exception {
System.out.println("u.t: " + System.getProperty("user.timezone"));
System.out.println("a date: " + new Date());
System.out.println("timezone: " + TimeZone.getDefault());
System.out.println("u.t: " + System.getProperty("user.timezone"));
}
}
---------- END SOURCE ----------
Comments
|