United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4255109 : (tz) TimeZone should support historical time zone name changes

Details
Type:
Enhancement
Submit Date:
1999-07-19
Status:
Open
Updated Date:
2013-07-31
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
solaris_9,linux,generic,windows_xp,windows_2000
Sub-Component:
java.time
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
1.3.0,1.4.1,1.4.2,5.0,5.0u8,6
Targeted Versions:
9

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

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.
                                     
2013-05-20
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
                                     
2000-11-10



Hardware and Software, Engineered to Work Together