JDK-4150039 : The Time Zone id name for Japan is wrong.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_95
  • CPU: generic
  • Submitted: 1998-06-18
  • Updated: 1999-03-18
  • Resolved: 1999-03-18
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.2.0 1.2Fixed
Related Reports
Relates :  
Description
In windows95 Japanese, java is one hour too fast.
I've first thought this is just TimeZone instance, but testing following
case shows more severe problem.

Run the following program.

Program : DateTime.java
--------------------------------------------------------------------------
	import java.util.Date;
	import java.util.TimeZone;

	public class DateTime {
  	  public static void main(String[] arg) {
    	    Date now = new Date();
    	    System.out.println(now);
    	    System.out.println(TimeZone.getDefault().getID());
  	  }
	}
--------------------------------------------------------------------------

Result at 14:10
--------------------------------------------------------------------------
	1998/06/16 15:10:24 GMT+10:00 1998
	Asia/Yakutsk	
--------------------------------------------------------------------------

Above line of result show one hour forward. Notice that JST(Japan Standard Time) is GMT+9:00.
The next line, 'Yakutsk' is Russian City. This should be like 'Asia/Tokyo'.
When I use DateFormat for formating, result is same.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2 FIXED IN: 1.2 INTEGRATED IN: 1.2
14-06-2004

EVALUATION Windows 95 is returning the wrong values. Workaround will be added for JDK 1.2 beta 4. mark.son-bell@eng 1998-06-30 The suggested fix should be evaluated for FCS (see Comments). masayoshi.okutsu@Eng 1998-09-03 I believe this to be a duplicate of 4141080. May I close it as such? alan.liu@eng 1998-09-11 According to alanl@eng, this bug is now masked by the 4141080 workaround that we're putting into 1.2 FCS. We still need to figure out what the best approach is for initializing time zones, but the workaround is sufficient for 1.2 FCS. norbert.lindenberg@Eng 1998-09-22 I just tried the suggested fix out on Japanese Windows 95 and English NT 4. Unfortunately, it did not work correctly for me. GetTimeZoneInformation()'s return value cannot be used, at least on Japanese Win95, to differentiate daylight from standard zones. I believe the table mechanism used to fix 4141080 and 4167800 will have to do. I am closing this for now. Reopened per discussion with Koushi Takahashi <###@###.###>. Who reopened this? If someone is going to reopen this, they must supply additional specific technical information addressing the results of my investigation mentioned above. GetTimeZoneInformation() does not perform as advertised, and the suggested fix causes the code to generate incorrect information on the platforms I tested, including Japanese Win95. I would like to close this in a week or so if no more information is forthcoming. alan.liu@eng 1999-03-02 The 1.2beta4 workaround works OK for the Japanese Win32 platforms. I"m closing this bug. masayoshi.okutsu@Eng 1999-03-18 Some additional info: Koushi Takahashi <###@###.###> on 03/17/99 11:52:32 PM To: Alan Liu/Raleigh/Contr/IBM cc: Masayoshi Okutsu <###@###.###>, Francis Tsang <###@###.###>, Laura Werner/Cupertino/IBM Subject: Re: [Fwd: 4150039] Alan, Just in case. To validate the code in suggested fix, I used following program. --- test.c --- #include<windows.h> #include<stdio.h> #include<winbase.h> void main() { TIME_ZONE_INFORMATION tzi; int i; DWORD gtzi = GetTimeZoneInformation(&tzi); printf("gtzi: %d\n", gtzi); if(gtzi == 0) printf("Unknown\n"); if(gtzi == 1) printf("Standard\n"); if(gtzi == 2) printf("Daylight\n"); printf("DaylightBias: %d\n", tzi.DaylightBias); printf("StandardBias: %d\n", tzi.StandardBias); printf("Bias: %d\n", tzi.Bias); for (i = 0; tzi.StandardName[i] !='\0'; i++ ) { printf("\\u%004lx",tzi.StandardName[i]); } printf("\n"); for (i = 0; tzi.DaylightName[i] !='\0'; i++ ) { printf("\\u%004lx",tzi.DaylightName[i]); } printf("\n"); } ---- The result on win95/98 Japanese Date TimeZone gtzi DaylightBias StandardBias Bias 3/18 JST 1 -60 0 -540 PST 1 -60 0 480 8/18 JST 1 -60 0 -540 PST 2 -60 0 480 The result on WinNT4.0 Japanese Date TimeZone gtzi DaylightBias StandardBias Bias 3/18 JST 0 0 0 -540 PST 1 -60 0 480 8/18 JST 0 0 0 -540 PST 2 -60 0 480 The line in 'java_props_md.c' test whether host is running on DST by, hasDST = tzi.DaylightBias == 0 ? kStandard : kDaylight; On win95/98, as above program shows, the test is not valid. Anyway, as wrote in evaluation, the fix for 4141080 masks the problem above. Also, the value 'hasDST' seems not be used on elsewhere. So, I found no problem on current code. Koushi
11-06-2004

SUGGESTED FIX ${JDK}/src/win32/hpi/src/system_md.c GetTimeZoneInformation has some uncertainness on bias value. When GetTimeZoneInformation returns TIME_ZONE_ID_STANDARD or TIME_ZONE_ID_UNKNOWN, the value in tzi.DaylightBias is invalid. Suggested fix here check API return value. *** system_md.c Mon Jun 29 17:53:54 1998 --- /tmp/system_md.c Mon Jun 29 17:46:09 1998 *************** *** 436,443 **** TIME_ZONE_INFORMATION tzi; char *std_timezone = NULL; ! if (GetTimeZoneInformation(&tzi) == -1) { /* The call to GetTimeZoneInformation failed. We can't do anything * at all in this case. We can't even synthesize a GMT+hh:mm name, * since we don't have the offset. */ --- 436,444 ---- TIME_ZONE_INFORMATION tzi; char *std_timezone = NULL; + DWORD tzi_ret; ! if ((tzi_ret = GetTimeZoneInformation(&tzi)) == -1) { /* The call to GetTimeZoneInformation failed. We can't do anything * at all in this case. We can't even synthesize a GMT+hh:mm name, * since we don't have the offset. */ *************** *** 478,484 **** int match, offset; enum EHasDST hasDST; ! hasDST = tzi.DaylightBias == 0 ? kStandard : kDaylight; offset = -tzi.Bias; /* Conventions reversed between Win32 & us */ match = -1; --- 479,489 ---- int match, offset; enum EHasDST hasDST; ! //hasDST = tzi.DaylightBias == 0 ? kStandard : kDaylight; ! if(tzi_ret == TIME_ZONE_ID_STANDARD || tzi_ret == TIME_ZONE_ID_UNKNOWN) ! hasDST = kStandard; ! else ! hasDST = tzi.DaylightBias == 0 ? kStandard : kDaylight; offset = -tzi.Bias; /* Conventions reversed between Win32 & us */ match = -1; [koushi.takahashi@japan 1998-06-29]
29-06-1998