• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSDateFormatter not working on iOS 5.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Re: NSDateFormatter not working on iOS 5. (From: Peter Edberg <email@hidden>)
 >Re: NSDateFormatter not working on iOS 5. (From: John Joyce <email@hidden>)

  • Prev by Date: Re: Playing Music in Objective C
  • Next by Date: Re: Playing Music in Objective C
  • Previous by thread: Re: NSDateFormatter not working on iOS 5.
  • Next by thread: Multiple Selection in NSComboBoxCell
  • Index(es):
    • Date
    • Thread