On Feb 2, 2012, at 7:56 AM, John Joyce wrote: > > On Feb 2, 2012, at 2:20 AM, Peter Edberg wrote: > >> >> On Jan 31, 2012, at 2:35 PM, cocoa-dev-requ...@lists.apple.com wrote: >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 31 Jan 2012 14:10:13 -0600 >>> From: Heath Borders <heath.bord...@gmail.com> >>> To: cocoa-dev <cocoa-dev@lists.apple.com> >>> >>> Peter, >>> >>> If I set the locale to "en_IN" shouldn't that show the short time zone? >>> >>> NSLocale *indianEnglishLocale = [[[NSLocale alloc] >>> initWithLocaleIdentifier:@"en_IN"] autorelease]; >>> NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@"Asia/Kolkata"]; >>> NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] >>> autorelease]; >>> dateFormatter.locale = indianEnglishLocale; >>> dateFormatter.dateFormat = @"z"; >>> dateFormatter.timeZone = timeZone; >>> >>> NSLog(@"date string: %@", [dateFormatter stringFromDate:[NSDate date]]); >>> NSLog(@"time zone abbreviation: %@", [timeZone >>> abbreviationForDate:[NSDate date]]); >>> >>> output: >>> >>> date string: GMT+05:30 >>> time zone abbreviation: IST >>> >>> -Heath Borders >> >> >> 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 >>
> Is there any recommended workaround approach for this kind of scenario until > those updates are incorporated? > More specifically, how would one best implement a workaround that would be > easily overridden by (or not clash terribly) the fix when it is eventually > incorporated into a release? > Any best practices or recommendations in that area? I will need to think about the best current workaround for this, but right now I am (and have been) swamped, sorry. - Peter E > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
