NSDateFormatter does not show the time zone abbreviation for "Asia / Kolkata" for the specifier "z" or "zzz", only GMT offset

Question

On iOS5 simulator and device, NSDateFormatter does not display the time reduction for "Asia / Kolkata" for the "z" or "zzz" qualifier.

NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@"Asia/Kolkata"]; NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease]; dateFormatter.dateFormat = @"z"; // or @"zzz" dateFormatter.timeZone = timeZone; NSLog(@"date string: %@", [dateFormatter stringFromDate:[NSDate date]]); // "GMT+05:30", expected "IST" NSLog(@"time zone abbreviation: %@", [timeZone abbreviationForDate:[NSDate date]]); // "IST" 

I expect the code output above:

 IST IST 

but it produces:

 GMT+05:30 IST 

EDIT

Setting the locale to locale does not help.

 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:@"z"]; // or @"zzz" [dateFormatter setTimeZone:timeZone]; NSLog(@"date string: %@", [dateFormatter stringFromDate:[NSDate date]]); // "GMT+05:30", expected "IST" NSLog(@"time zone abbreviation: %@", [timeZone abbreviationForDate:[NSDate date]]); // "IST" 

I expect the code output above:

 IST IST 

but it produces:

 GMT+05:30 IST 

This is mistake? Am I doing something wrong? People mentioned that NSDateFormatter has errors, especially if the time zone is specified in the format string. Could this be one of these mistakes?

Answer 1

From http://www.cocoabuilder.com/archive/cocoa/310977-nsdateformatter-not-working-on-ios-5.html#311281

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

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

For "en" locale (= "en_US"), the cu flag is set for metazones such as Alaska, America_Central, America_Asterich, America_Monten, America_Pacific, Atlantic, Hawaii_Aleutian and GMT. It is not installed for Europe_Central.

However, for the "en_GB" locale, the cu flag is set to Europe_Central.

So, the formatter set for the short time zone "z" or "zzz" and locale "ru" or "en_US" will not parse "CEST" or "CET", but if the locale is set to "en_GB" instead, it will parse them. Style "GMT" will be analyzed by everyone.

If the formatting is set to the long time zone style "zzzz" and locale is any of the "en", "en_US" or "en_GB", then any of the following will be analyzed because they are unambiguous: "Pacific Daylight Time" "Central European Daylight Saving Time "Central European Time"

Hope this helps.

• Peter Edberg

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

Hit, Yes, you're right, for the example that you specified above, [dateFormatter stringFromDate: [NSDate date]] should use the short name of the time zone "IST". The fact that this is not the case is due to a lack of local "en_IN" data in the CLDR data versions used by ICUs in current OSX and iOS releases (CLDR 1.9.1 and 2.0, respectively). The locale "en_IN" in these versions of CLDR did not redefine or supplement any data on the name of the time zone from the base language "en", whose default content is for "en_US".

This has already been fixed for the release of CLDR 21 following a few days. This is included in OIT 49, which will be future releases of OSX and iOS.

• Peter E

--- Edit ---

According to the Unicode documentation on the formats and their rules , the V format may have been a better choice:

... in the same format as z, except that the abbreviations of the time zones of the metazone should be displayed, if available, regardless of the value of [the] commonUsed [flag].

In my case, for the following code:

 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]]); 

I get the following output:

 V date string: IST