Zone Localizations

2003-07-28, MD
http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/gmt_translations.html

Background

When ICU formats or parses a date pattern containing a "z" parameter (for time-zone), then it uses the Olson IDs to look up a localized name, if available. For example:

"hh 'o''clock' a, zzzz" ->> 12 o'clock PM, Pacific Daylight Time

If there are no localized names for a given Olson ID, then it falls back to using a format like "GMT+12:00", so for another time-zone the above pattern might produce:

"hh 'o''clock' a, zzzz" ->> 11 o'clock AM, GMT-09:00

The current data for this is of the format:

{	"America/Los_Angeles",	// Olson ID
	"Pacific Standard Time",	// standard time name
	"PST",			// short standard
	"Pacific Daylight Time",	// daylight time name
	"PDT",			// short daylight
	"Los Angeles"		// exemplar city
}

For more information, see:

Problems

  1. Currently the fallback format is hard-coded, which is prima facie a problem, since one can't translate "GMT" or ":" into strings more appropriate for other languages, and the ordering of elements is fixed. Moreover, the GMT+/- format itself may not be customary in a given country; while many programmers may be familiar with it, end users may not be familiar with "GMT", or may not want to 'do the math'. There is also no way to explicitly indicate that you want the fallback with a pattern; it is only available if the translated zone strings are not available.
  2. We have no way to get the wall time, which is normally much more useful than the explicit time. Normally people schedule events according to wall time. For example, a 9:30 AM meeting will be expected to be at 9:30 AM wall time, no matter what time of year it is. People don't say: "let's meet at 9:30 EST", meaning that during the summer they meet at 8:30!
  3. We don't currently use the exemplar city, although that is in many ways the best time indication for end-users, e.g. 3:00 PM New Delhi Time.

Proposed Solution

We will allow the following characters in patterns. Red is new.

  Pattern Characters Meaning Example
1 zzzz Explicit Zone Pacific Standard Time / Pacific Daylight Time
2 z Short Explicit Zone PST / PDT
3 ZZZZ GMT Offset GMT+06:30
4 ZZZ City Zone New Delhi Time
5 ZZ Generic (Wall-time) Zone Pacific Time
6 Z Short Generic (Wall-time) Zone PT
7 zz Default (indirect) Zone any of above, depending on default format setting.

The default zone will allow sublocales to easily change the default from explicit to wall or city time. It essentially provides one level of indirection.

We will be changing our data anyway to upgrade to LDML, adding the generic (wall-time), and we want to change the ICU resource to be a tagged array, so we use a tool to will change the ICU data to be of the form:

America_Los_Angeles {	// Olson ID (now as key)
	"Los Angeles",		// exemplar city
	"Pacific Time",		// generic zone name
	"PT",			// short generic
	"Pacific Standard Time",	// standard zone name
	"PST",			// short standard
	"Pacific Daylight Time",	// daylight zone name
	"PDT",			// short daylight
}

The reason we will change the ordering is because it corresponds more to the data that will be available for localization. That is, it is likely that for many locales we will (at first) only have the cities. We will treat these as variable-length lists on lookup, so the most important items will be first. As a part of this data generation, we will use the city names from the Olson data for the English city names (cleaned up a bit, e.g. replacing underscores), so all of the Olson IDs will have zone resources in en.txt. In the near-term, we will get those cities translated for Group 1 (English, Japanese, German, Chinese (simplified), Chinese (traditional), French, Spanish, Italian, Portuguese (Brazilian), Korean).

We will add the following tags to resource bundles:

gmtZoneFormat: "GMT {0,number,+0;-0}:{1,number,00}" // for support of localized #1 format
cityZoneFormat: "{0} Time" // for support of localized #2 format
defaultZoneFormat: "ZZZ" // sets the default to be city zone format

The first one is a MessageFormat used to format/parse the GMT zone format. The second is a message format used to format the city zone format. The third one is what the default zone pattern (a 'zz') maps to.

We will recommend to the Locale Data Markup Language group that elements be added to the standard DTD for these as subelements of <timeZoneNames>, to wit:

<timeZoneNames defaultZoneFormat="ZZZ">
  <gmtZoneFormat>GMT {0,number,+0;-0}:{1,number,00}</gmtZoneFormat>
  <cityZoneFormat>{0} Time</cityZoneFormat>
  ...

We will also institute multi-level fallback for zone resources. So if a key is missing in, say, en_US, then it will be looked up in en. The root will be as language neutral as possible, and contain no translated zone strings; that means that the raw Olson IDs will be returned if we ever make it all the way up to the root.