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 On Mon, Nov 21, 2011 at 1:54 AM, Peter Edberg <pedb...@apple.com> wrote: > > On Nov 17, 2011, at 10:14 AM, Matt Neuburg wrote: > >> On Wed, 16 Nov 2011 14:43:55 -0800, Peter Edberg <pedb...@apple.com> said: >>> ... >>> >>> The issue is this: With the *short* timezone formats as specified by z >>> (=zzz) or v (=vvv), there can be a lot of ambiguity. For example, "ET" for >>> Eastern Time" could apply to different time zones in many different >>> regions. To improve formatting and parsing reliability, the short forms are >>> only used in a locale if the "cu" (commonly used) flag is set for the >>> locale. Otherwise, only the long forms are used (for both formatting and >>> parsing). >>> >>> For the "en" locale (= "en_US"), the cu flag is set for metazones such as >>> Alaska, America_Central, America_Eastern, America_Mountain, >>> America_Pacific, Atlantic, Hawaii_Aleutian, and GMT. It is *not* set for >>> Europe_Central. >>> >>> However, for the "en_GB" locale, the cu flag *is* set for Europe_Central. >>> >>> So a formatter set for short timezone style "z" or "zzz" and locale "en" or >>> "en_US" will not parse "CEST" or "CET", but if the locale is instead set to >>> "en_GB" it *will* parse those. The "GMT" style will be parsed by all. >>> >>> ... >> >> Thanks; I suspected that something like this might be the case. But the >> result, as I pointed out in my bug report (10447767), is that you can't >> round-trip the abbreviations that the system itself gives you: >> >> NSDictionary* d = (NSDictionary*)CFTimeZoneCopyAbbreviationDictionary(); >> for (NSString* aZone in d.keyEnumerator) >> NSLog(@"%@ %@", aZone, [dateFormatter dateFromString: >> [NSString stringWithFormat:@"2011-11-15 06:50:59.735 %@", aZone]]); >> >> These are *your* abbreviations (by "you" I mean the system) that aren't >> working. If they aren't going to work why are you giving them to me? Surely >> there should be some call that provides me with a list of *legal* >> abbreviations. m. > > > > Yes, there is a disconnect here. The dictionary returned by > CFTimeZoneCopyAbbreviationDictionary (and by +[NSTImeZone > abbreviationDictionary]) is a standard internal mapping that does not depend > on locale and is not built from the abbreviations used by ICU, and always > maps ambiguous zone abbreviations to a particular zone name (as noted in the > documentation) regardless of locale. This is not particularly useful for your > purposes. > > What would be more useful in this case is function that takes a locale > parameter, and returns a dictionary of the abbreviation mappings that are > meaningful in that locale. This would be built from the locale-specific > abbreviations used by ICU. If you agree, please file an enhancement request. > > - 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: > http://lists.apple.com/mailman/options/cocoa-dev/heath.borders%40gmail.com > > This email sent to heath.bord...@gmail.com _______________________________________________ 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
