Re: NSDateFormatter not working on iOS 5.
Re: NSDateFormatter not working on iOS 5.
- Subject: Re: NSDateFormatter not working on iOS 5.
- From: Peter Edberg <email@hidden>
- Date: Mon, 13 Feb 2012 10:09:51 -0800
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, email@hidden wrote:
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 31 Jan 2012 14:10:13 -0600
>>> From: Heath Borders <email@hidden>
>>> To: cocoa-dev <email@hidden>
>>>
>>> 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 (email@hidden)
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:
This email sent to email@hidden