On Sun, 20 Nov 2011 23:54:45 -0800, Peter Edberg <pedb...@apple.com> said: > >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.
Thanks, Peter - I've added that suggestion to my original bug report (problem ID 10447767). I used your name too. :) m. -- matt neuburg, phd = m...@tidbits.com, <http://www.apeth.net/matt/> A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook_______________________________________________ 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
