The change in parsing of abbreviated time zone names in iOS 5.0 is a
result of an intentional change in the open-source ICU 4.8 library
(and the open-source CLDR 2.0 data that it uses),a modified version
of which is used to implement some of the NSDateFormatter
functionality.

The issue is this: With the short timezone formats as specified by z
(=zzz) or v (=vvv),there can be a lot of ambiguity. For example,“ET”
for Eastern Time” could apply to different time zones in many
different regions. To improve formatting and parsing reliability,the
short forms are only used in a locale if the “cu” (commonly used) flag
is set for the locale. Otherwise,only the long forms are used (for
both formatting and parsing).

For the “en” locale (= “en_US”),the cu flag is set for Metazones such
as Alaska,America_Central,America_Eastern,America_Mountain,
America_Pacific,Atlantic,Hawaii_Aleutian,and GMT. It is not set
for Europe_Central.

However,for the “en_GB” locale,the cu flag is set for
Europe_Central.

So a formatter set for short timezone style “z” or “zzz” and locale
“en” or “en_US” will not parse “CEST” or “CET”,but if the locale is
instead set to “en_GB” it will parse those. The “GMT” style will be
parsed by all.

If the formatter is set for the long timezone style “zzzz”,and the
locale is any of “en”,“en_US”,or “en_GB”,then any of the following
will be parsed,because they are unambiguous: “Pacific Daylight Time”
“Central European Summer Time” “Central European Time”

Hope this helps.

• Peter Edberg

从http://www.cocoabuilder.com/archive/cocoa/313301-nsdateformatter-not-working-on-ios-5.html#313301开始

Heath,
Yes,you are correct,for the example you provided above,
[dateFormatter stringFromDate:[NSDate date]] should use the short
time zone name “IST”. The fact that it does not is due to a deficiency
in the “en_IN” locale data in the versions of CLDR data used by ICU in
the current OSX and iOS releases (CLDR 1.9.1 and 2.0 respectively).
The “en_IN” locale in those CLDR versions did not override or
supplement any of the timezone name data from the base “en” locale,
whose default content is for “en_US”.

This is already fixed for the CLDR 21 release coming in a few days.
That is being incorporated into ICU 49 which will be picked up in
future OSX and iOS releases.

• Peter E

– -编辑 – –

根据formats及其rules的unicode文档,V格式可能是更好的选择：

…the same format as z,except that Metazone timezone abbreviations are to be displayed if available,regardless of the value of [the] commonlyUsed [flag].

就我而言,对于以下代码：

NSLocale *indianEnglishLocale = [[[NSLocale alloc] initWithLocaleIdentifier:@"en_IN"] autorelease];
NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@"Asia/Kolkata"];
NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease];
[dateFormatter setLocale:indianEnglishLocale];
[dateFormatter setDateFormat:@"V"];
[dateFormatter setTimeZone:timeZone];

NSLog(@"V date string: %@",[dateFormatter stringFromDate:[NSDate date]]);

我收到以下输出：

V date string: IST