1

我正在尝试解析这个日期时间戳开始字符串：

Wed, 11 Sep 2013 08:51:41 EEST

这个问题只有

东部标准时间

, 我试过 z 或 zzz 或 V，什么也没发生。日期格式化程序始终为 NULL。

当我从字符串中删除 EEST 时，一切正常。

任何人都可以建议，如何解决这个问题？

谢谢

更新：

dateFormat = [[NSDateFormatter alloc] init];
[dateFormat setLocale:[[NSLocale alloc] initWithLocaleIdentifier:@"en_EN_POSIX"]];
[dateFormat setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"EEST"]];
[dateFormat setDateFormat:@"EEE, dd MMM yyyy HH:mm:ss V"];
dateFromString = [dateFormat dateFromString:beginString];
4

2 回答 2

3

试试这个：

NSString *beginString = @"Wed, 11 Sep 2013 08:51:41 EEST";
NSDateFormatter *dateFormat = [[NSDateFormatter alloc] init];
[dateFormat setLocale:[[NSLocale alloc] initWithLocaleIdentifier:@"en-GB"]];
[dateFormat setDateFormat:@"EEE, dd MMM yyyy HH:mm:ss zzz"];
NSDate *dateFromString = [dateFormat dateFromString:beginString];

在此处查看详细信息和说明

于 2013-09-12T13:21:34.787 回答
3

您对此问题的解决方案是将语言环境更改为en_GB，日期格式化程序将能够正确解析您的日期字符串。

以下是 Apple 开发人员错误报告团队对雷达 #9944011的解释：

这是 iOS 5 中的一个有意更改。问题在于：对于由 z (=zzz) 或 v (=vvv) 指定的短格式，可能会有很多歧义。例如，“东部时间”的“ET”可以应用于许多不同地区的不同时区。为了提高格式化和解析的可靠性，只有在“cu”（常用）标志设置为语言环境。否则，仅使用长格式（用于格式化和解析）。这是开源 CLDR 2.0 / ICU 4.8 中的更改，这是 iOS 5 中 ICU 的基础，而这又是基础NSDateFormatter 行为。

对于“en”语言环境（=“en_US”），为诸如 Alaska、America_Central、America_Eastern、America_Mountain、America_Pacific、Atlantic、Hawaii_Aleutian 和 GMT 等元区域设置了 cu 标志。它不是为 Europe_Central 设置的。

但是，对于“en_GB”语言环境，为 Europe_Central 设置了 cu 标志。

因此，为短时区样式“z”或“zzz”和语言环境“en”或“en_US”设置的格式化程序将不会解析“CEST”或“CET”，但如果将语言环境设置为“en_GB”，它将解析那些。“GMT”样式将被所有人解析。

如果格式化程序设置为长时区样式“zzzz”，并且语言环境是“en”、“en_US”或“en_GB”中的任何一个，那么将解析以下任何一个，因为它们是明确的：

“太平洋夏令时间” “中欧夏令时间” “中欧时间”

于 2013-09-12T13:24:58.663 回答