JDK-4108407 : Chinese time zone CTT is not recogonized correctly.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.1.6,1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,solaris_2.6
  • CPU: generic,sparc
  • Submitted: 1998-01-30
  • Updated: 1998-04-09
  • Resolved: 1998-04-09
Related Reports
Duplicate :  
Duplicate :  
Description
Platform Chinese Windows 95 - ** Time zone set to CST **
JDK1.1.6 build F

Run the following program
=======================DateFormatTest.java==================================
import java.text.*;
import java.util.*;

public class DateFormatTest {
    public static void main(String args[]) {
        long l = System.currentTimeMillis();
		System.out.println("Time Zone      :" +  
                    DateFormat.getDateInstance().getTimeZone().getID());
		System.out.println("Default format :" +
                    DateFormat.getDateInstance().format(new Date(l)));
		System.out.println("Full format    :" + 
                    DateFormat.getDateInstance(DateFormat.FULL).format(new
                    Date(l)));
	}
}

Set Locale to zh
=======================Output===============================================
java DateFormatTest


output with JDK1.1.6
Time Zone      :GMT   **** PROBLEM*****
Default format :1998-1-21
Full format    :1998Dj1TB21HU

The output doesn't show the time zone correctly.


Comments
PUBLIC COMMENTS The fix is not working for zh_TW locale
10-06-2004

EVALUATION In windows 95, mapping between native time zone value and java time zone fails. In Japanese & Chinese (Simplified) Windows 95 return the translated time zone string. Java runtime checks this value against english time zone string which indeed fails. Traditional Chinese win95 returns time zone returns the name in English. =============================== This fix only works on zh not on zh_TW With jdk1.1.6 under zh_TW on Win95, no matter what time zone you set (set Time zone to PST), you always get CTT as return. It seems "CTT" is hard coded in the code for zh_TW locale. Also this fix is not in JDK 1.2 yet. That is, if you use jdk1.2 on Win95 with zh, zh_TW, or ja locale, you always get GMT as time zone. cindy.jao@eng 1998-03-18 [xueming.shen@Japan 1998-03-19] I have filed a bug 4038617 against the current implementation of timezone guessing mechanism and offered a suggested fix for win32, yes, it's not complete due to my limited understanding that moment, but it works, and I do believe it should give the responsible engineer some hints about what's the porblem is and how to fix it, but finally VM team took the approach to pickup the timezone name from the current languageID (find the timezone name from a hard coded map table in locale_str.h) if the matching/guessing by using the return value from GetTimeZoneInformation() is failed, which means, for zh/ja/tw/ko and all other no English speaking locale, if the machine is not running at the correct geographic location, VM can never get the correct TimeZone info by default. Unfortunately Bud 4038617 has been closed for "duplicat reason", but after tracing the "duplicated target", I noticed it ends up at a Solaris timezone related bug, nothing to do with the Win32 problem we are talking about. So please take a look at my suggestion in 4038617, it may give some hints on how to fix this bug completely (can we? Okutsu-san and I have talked about this problem for a while, think too many things need to be cleaned up in the TimeZone...) =========================== This bug has not been fixed on Solaris for both zh and zh_TW, whereas it has been fixed on win95 for zh. cindy.jao@eng 1998-03-19 =========================== The bug is specific to win32 and has been fixed. The comments written in the bug seems to be misleading into Solaris bug. From my recollection of memory, there was a bug against JDK regarding default time zone. Taligent fixed the bug on Solaris as well as windows Taligent's fix did not work for win32 platform and it also showing as regression for JDK116. We patched JVM to behave like JDK1.1.5 even though we know that is not right behaviour. The bug is yet to be addressed in JDK1.2 but is not a regression from JDK1.1.5 I removed the 116regress keyword based on the comments above from Senthil Shanmugam from email on 3/25. debra.chapatte@eng 1998-03-27
27-03-1998

SUGGESTED FIX Wintel returns localized strings for time zone names. There is no convenient work around. To fix the regression guess the time zone value from locale if it can't be found from time zone name returned from native platform shanmugam.senthil@Eng 1998-02-13 ======================================= Here is the result I got from runing t.c and CheckTZ.java You can get t.c and CheckTZ.java from attachments. Apparently, for Taiwan and PRC timezone, we got worng the results from java, whereas the results from c is correct. setenv TZ Taiwan ./a.out TimeZone = [Taiwan][ ] java CheckTZ Now Time Zone is GMT setenv TZ PRC ./a.out TimeZone = [CST][CDT] java CheckTZ Now Time Zone is CST etenv TZ US/Central ./a.out TimeZone = [CST][CDT] java CheckTZ Now Time Zone is CST setenv TZ Japan ./a.out TimeZone = [JST][ ] java CheckTZ Now Time Zone is JST setenv TZ CTT ./a.out TimeZone = [CTT][ ] java CheckTZ Now Time Zone is CT cindy.jao@eng 1998-03-19
19-03-1998