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.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-4832236 - REGRESSION: (new Date(0L)).toString() == "Thu Jan 01 01:00:00 GMT 1970"
Duplicate :  
JDK-4844459 - setTimeInMillis adding an extra hour as default
Duplicate :  
JDK-6417469 - (tz) Iran stopped using daylight saving
Duplicate :  
JDK-6609362 - (tz) Epoch GMT offset causes unexpected behaviour in SimpleDateFormat parsing
Duplicate :  
JDK-8058523 - Wrong timezone shortcode output for Europe/London for 1971-10-31 01:59:59 UTC
Duplicate :  
JDK-6644488 - [Fmt-Da] SimpleDateFormat with zzz pattern loose 1 hour when parsing from 1900 to 1940
Duplicate :  
JDK-6644494 - [Fmt-Da] SimpleDateFormat do not use timezone historic offset change during parsing
Duplicate :  
JDK-6433699 - SimpleDateFormat formats 'z' as GMT, 'Z' as +0100
Duplicate :  
JDK-6609419 - Time zone wrong when "Automatically adjust clock DST" is selected in win XP
Relates :  
JDK-4247995 - Wrong timezone abbreviations (CTT, AST, etc.) used as time zone IDs
Relates :  
JDK-6801246 - javazic tool outputs a warning message with tzdata2009a
Description
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	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
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.)
Comments
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.
20-05-2013
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
10-11-2000