The change in parsing of abbreviated time zone names in iOS 5.0 is a result of an intentional change in the open-source ICU 4.8 library (and the open-source CLDR 2.0 data that it uses), a modified version of which is used to implement some of the NSDateFormatter functionality.
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. If the formatter is set for the long timezone style "zzzz", and the locale is any of "en", "en_US", or "en_GB", then any of the following will be parsed, because they are unambiguous: "Pacific Daylight Time" "Central European Summer Time" "Central European Time" Hope this helps. - Peter Edberg > Date: Wed, 16 Nov 2011 16:29:41 +0800 > From: Kin Mak <kin...@me.com> > Subject: Re: NSDateFormatter not working on iOS 5. > To: Matt Neuburg <m...@tidbits.com> > Cc: cocoa-dev@lists.apple.com > > Matt, > > The result differs not only on simulator, but also on iphones running 4.3 and > 5.0. > I have also found out that ONLY some of the known time zones work fine on > 5.0. e.g. PDT, PST, GMT ...etc. However, all time zones work fine on iOS 4.3. > In fact, I have already reported this as a bug to apple. > > Thanks and Regards > Kin > > On Nov 15, 2011, at 11:11 PM, Matt Neuburg wrote: > >> By the way, I can readily confirm that the results differ on the simulator >> for 4.3 vs. 5.0. m. >> >>> On Fri, 11 Nov 2011 16:13:49 +0800, Kin Mak <kin...@me.com> said: >>>> The following code used to work fine prior to iOS 5. The dateFromString >>>> method seems to stop working on iOS 5 and always returns null. I suspect >>>> this is a bug introduced in iOS 5.0. Have anyone encountered the same >>>> issue? Or do I miss something here? >>>> >>>> NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init]; >>>> [dateFormatter setDateFormat:@"yyyy-MM-dd HH:mm:ss.SSS zzz"]; >>>> >>>> ..... >>>> //E.g currentString = @"2011-11-11 11:00:00.000 CET"; >>>> NSDate *date = [dateFormatter dateFromString:currentString]; >>> >>> It works for me if I substitute "PST" for your "CET" - could the "CET" be >>> the problem? >>> >>> I guess what I would do is start by testing whether the date formatter can >>> round-trip its own output, like this: >>> >>> NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init]; >>> [dateFormatter setDateFormat:@"yyyy-MM-dd HH:mm:ss.SSS zzz"]; >>> NSString* output = [dateFormatter stringFromDate:[NSDate date]]; >>> NSLog(@"%@", output); >>> >>> NSDate* date = [dateFormatter dateFromString: output]; >>> NSLog(@"%@", date); >>> >>> It can on my machine (PST). If it can't on your machine, that sounds like a >>> bug. >>> >>> Also, do try -[dateFormatter getObjectValue:forString:errorDescription:]; >>> It is definitely throwing an error (not very helpful, "The operation >>> couldn't be completed") for your string on my machine. >>> _______________________________________________ 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
