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> >> Subject: Re: NSDateFormatter not working on iOS 5. >> Message-ID: >> <caey7hvoe-71ecttjopluw8b-9qymhczjhtbwj+gmmenod8w...@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> 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.bord...@gmail.com >> Twitter: heathborders >> http://heath-tech.blogspot.com > > > 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?
_______________________________________________ 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
