JDK-6355791 : JCK14a - api TimeZone static test fails for 142_11b1 on Windows 32bit jvm "returns wrong offset"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.2_11
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2005-11-28
  • Updated: 2013-02-20
  • Resolved: 2005-12-09
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.
Other
1.4.2_11 b02Fixed
Related Reports
Relates :  
JDK-6332148 - (tz) Support tzdata2005n
Relates :  
JDK-6277315 - JCK: api/java_util/TimeZone/index.html#static fails on Win 2000, Win XP Home
Description
JDK Info: java version "1.4.2_11-ea"
Build: 1.4.2_11-ea-b01

Testsuite: JCK-runtime-14a
Test: javasoft.sqe.tests.api.java.util.TimeZone.staticTests
Configuration: Any Windows OS with 1.4.2_11-ea-b01 32 bit windows-i586 bundle installed.

Output from testrun:

TimeZone2013: Failed. TimeZone.getAvailableIDs returns wrong result it contains ID : America/Fort_Wayne that is not supported
TimeZone2014: Failed. TimeZone.getAvailableIDs(rawOffset) returns wrong result it contains ID : AGT with wrong offset : 0rawOffset = -10800000
TimeZone0003: Passed. OK
TimeZone2015: Passed. OK
TimeZone0004: Passed. OK
TimeZone0005: Passed. OK
TimeZone0006: Passed. OK
TimeZone2017: Failed. TimeZone.getTimeZone(ID) returns a wrong value : sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]it has wrong ID = GMTID = America/Fort_Wayne
TimeZone2018: Passed. OK
TimeZone2019: Passed. OK
STATUS:Failed.test cases: 10; passed: 7; failed: 3; first test case failure: TimeZone2013

This test passes on Solaris and Linux with 32 bit jvm for 142_11b1.
This test also passes on Windows_X64 systems with 64bit jvm.
This test also passes on Windows OS with 32bit jvm for 142_10b3.

Summary of Results
-------------------
JDK Version	Bundle		Configuration	Result
-------------------------------------------------------
1.4.2_10b3	32bit jvm	WinXPHome_x86)	Passed
1.4.2_10b3	32bit jvm	Solaris 9	Passed

1.4.2_11b1	32bit jvm	WinXPHome_X86	Failed
1.4.2_11b1	32bit jvm	Solaris8	Passed
1.4.2_11b1	32 bit jvm	WinXP_Pro_X64	Failed
1.4.2_11b1	64 bit jvm	WinXp_Pro_X64	Passed

As you can see the failure is specific to Windows and 32bit jvm.
It is a regression introduced in 142_11b1.
Hi Edmund,

I have re-ran the test on winxphome and win2k again I see the failure.
That is now 5 different machines which I have reproduced the failure on.
Here is the WinXpHome machine which you can vnc into. where I have javatest running and you can see the failure with 1.4.2_11 32bit jvm installed into c:/j2sdk1.4.2_11.
The reason I was quick to log was because on winxp_pro_x64 when I had 32bit jvm installed the test failed. Once I installed windows-amd64 bundle the test pass.

machine: skinner.ireland
ip: 129.156.233.87
vnc pass: 

You will find masterGUI-14a.ksh and jvm_args.setup in c:/JQA/ts142/JCK_test
The TimeZone test is consistently failing on XP Home.  The .exe and .tar bundles have been used and different Locales tried.  Service Pack 2 is installed and the test machine has all current updates.
The TimeZone test is pass on x86 Windows XP Pro SP2 (qt7.ireland).  The .exe and .tar bundles have been used and different Locales tried. Probably problem is specific for Windows XP Home.
Patched or non-patched exe bundles were used on Windows XP Pro and it's all pass.
The test has been rerun on WinXPhome with the non patched exe bundle and is passing.  The issue seems to be occuring only with the patched bundle on XPhome.
Comments
EVALUATION Adding the following entry to indicate that the fix has been verified by the submitter: "JCK-runtime-14a complete testsuite has been re-run with the nighly patched 142_11 JRE your provided. Results are 100% Green. Rgds, Annemarie."
12-12-2005
SUGGESTED FIX The above suggested fix is for: install/src/windows/patchgen/patch.cmd
01-12-2005
SUGGESTED FIX 85,88d84 < < # Move the files to a new directory if they've moved < NOAUTOMATCH <
01-12-2005
EVALUATION According to ###@###.###, this bug is surfacing in 1.4.2_11 because of the backport for 6332148. It triggered 6277315 to appear as a result. 6277315 needs to be backported as a result, but in order for this backport to work, the build machines needs to have at least rtpatch version 8. ###@###.### has verified with release engineering that the build machines have rtpatch version 8.10, so this is not going to be an issue.
01-12-2005
EVALUATION So, judging from the mails, this looks like an install time issue. AnneMarie, to see if its related to the patching mechanism in 1.4.2, can you try installing the non-patched jdk.exe and execute the failing tests again. You may want to remove all other 1.4.2 JDKS installed on the system first of all. The non-patched exe is the bundle *without* the "-p"
30-11-2005
EVALUATION First, I have a modified version of the failing JCK tests so that I do not have to go through the harness to verify the failures. I have placed a copy of it on skinner.ireland at c:\Ed-JCK. I know that this version works because I was able to reproduce the failures you're seeing using my version. However, I also untarred a version of 1.4.2_11 b01 under c:\Ed-JCK and ran the very same tests and they come up passing. This leads me to start theorizing that there may be issues with the 1.4.2_11 setup on your machine. I wanted to try installing another 1.4.2_11 on the machine, but since it detected an existing version, it only allowed me to modify or remove the existing installation. I did not want to ruin the existing installation in case you still needed it. Therefore, can you please try some testing with my untarred JDK under c:/Ed-JCK to verify whether the problem is a setup issue? I got my JDK version from koori.sfbay. I assume you did the same, but just wanted to make sure. In case you would like to run my modified version of the JCK, just do the following: c:\Ed-JCK\j2sdk1.4.2_11\bin\java staticTests
29-11-2005
EVALUATION I tried running the tests on: 1) Windows XP Home 2) Windows XP Professional AMD64 All tests pass for both of these platforms.
28-11-2005
EVALUATION I tried running the JCK tests on: 1) Windows 2000 2) Windows XP Professional All tests passed on both of these platforms. The submitter reported that it happens on Windows XP Home, but if it fails on XP Home, then it should fail on 2000 and Prof. Please verify that the failures happen on 2000 and Prof, and re-verify that it happens on Home.
28-11-2005