NSDateFormatter doesn't parse some timezones

Number:rdar://9944011 Date Originated:12-Aug-2011 03:40 PM
Status:Closed Resolved:Behaves correctly
Product:iOS SDK Product Version:5.0
Classification:Serious Bug Reproducible:Always
On iOS 5.0b5 (9A5288d), NSDateFormatter is not able to parse a date string with the CET (Central European Time) or CEST (Central European Summer Time) timezone.

Steps to Reproduce:

NSLocale *enLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en"];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setLocale:enLocale];
[dateFormatter setDateFormat:@"yyyy-MM-dd HH:mm:ss zzz"];
NSLog(@"%@", [dateFormatter dateFromString:@"2011-08-12 13:37:00 PDT"]);
NSLog(@"%@", [dateFormatter dateFromString:@"2011-08-12 13:37:00 CET"]);
NSLog(@"%@", [dateFormatter dateFromString:@"2011-08-12 13:37:00 CEST"]);
NSLog(@"%@", [dateFormatter dateFromString:@"2011-08-12 13:37:00 GMT+2"]);

Expected Results:

2011-08-12 20:37:00 +0000
2011-08-12 12:37:00 +0000
2011-08-12 11:37:00 +0000
2011-08-12 11:37:00 +0000

Actual Results:

2011-08-12 20:37:00 +0000
2011-08-12 11:37:00 +0000

On iOS 4.3, the date formater is able to parse the dates with CET et CEST timezones and I get the expected results, respectively 2011-08-12 12:37:00 +0000 and 2011-08-12 11:37:00 +0000.


21-Sep-2011 11:39 PM Apple Developer Bug Reporting Team

Engineering has determined that this issue behaves as intended based on the following information:

This is an intentional change in iOS 5. The issue is this: With the short 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). This is a change in open-source CLDR 2.0 / ICU 4.8, which is the basis for the ICU in iOS 5, which in turn is the basis of NSDateFormatter behavior.

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"

By cedric.luthi at Oct. 13, 2011, 3:59 p.m. (reply...)

Flag activiated

How does on set the "cu" (commonly used) flag on NSLocale object?

By swthomas01 at Jan. 18, 2012, 4:06 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!