JDK-4255109 : (tz) TimeZone should support historical time zone name changes
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 1.3.0,1.4.1,1.4.2,5.0,5.0u8,6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS:
    generic,linux,solaris_9,windows_2000,windows_xp generic,linux,solaris_9,windows_2000,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 1999-07-19
  • Updated: 2018-09-11
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.
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
In many time zones, they switched time zones and therefore changed the time zone names. For example, the following is the history of Asia/Singapore.

# Singapore
Zone	Asia/Singapore	6:55:24 -	LMT	1880
			6:55:24	-	SMT	1905 Jun # Singapore Mean Time
			7:00	-	MALT	1933	 # Malaya Time
			7:20	-	MALT	1942 Feb 15
			9:00	-	JST	1945 Sep  2
			7:20	-	MALT	1950
			7:30	-	MALT	1965 Aug  9 # independence
			7:30	-	SGT	1982 May # Singapore Time
			8:00	-	SGT

The TimeZone class can't deal with these name changes.

Currently, timezone abbreviations are stored in java.text.resources.DateFormatZoneData<locale>. Therefore, timezone abbreviations unknown to a locale are not shown in the locale. Timezone abbreviations should not be dependent on a locale. (Timezone names should still be localizable.)

What I've vaguely been thinking is to: - concatenate tzid and Olson format values (e.g., "Asia/Singapore$SMT") except for the last one (e.g., no "Asia/Singapore$SGT", just "Asia/Singapore") - add historical names with indices to time zone binary data (e.g., 1 - "Asia/Singapore$SMT") - add a name index to each transition in time zone binary data - add historical names to TimeZoneNames. (e.g., { "Asia/Singapore$SMT", new String[] {"Singapore Mean Time", "SMT", ...}}) CLDR has a completely different approach -- name data has transition data. But that approach would have data maintenance problems.

EVALUATION Each timezone data should contain its abbrevinations. masayoshi.okutsu@Eng 1999-07-18 Historical time zone name changes can't be supported under the current structure of time zone data and display name resources. Also resources could be organized more efficiently. For example, if a time zone database holds an English name (e.g., "Pacific Standard Time"), each localization should have only its translation with the English name as a key. Currently, each time zone ID has a set of translated names, which structure requires duplicates. Note that an abbreviation can't be a unique key. Probably it's necessary to have a pair of long and abbreviation names under a long name key. masayoshi.okutsu@Eng 2000-11-10