问iOS应用程序偶尔会向REST发送格式无效的ISO8601日期。
EN

Stack Overflow用户

提问于 2015-07-06 22:34:18

回答 2查看 100关注 0票数 2

每天有几次，我们的PHP记录一个由无效格式的ISO8601日期引起的错误，这个错误来自iOS应用程序发送的GET请求。有趣的是，大多数电话都没问题。2015-07-07T00:00:00+10:00，但是我们经常会遇到一个奇怪的(例如。2015-07-07T12:00:00 am+10:00)。

我认为导致这种情况的代码如下：

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"yyyy-MM-dd'T'HH:mm:ssZZZZZ"];

NSString *iso8601StringStart = [dateFormatter stringFromDate:self.searchStartTime];

在什么情况下，NSDateFormatter可以(错误地)从“yyyy‘the :mm:ssZZZZZ”中获得am/pm，而这显然是意外的行为？是否有某种NSDate会导致不同的行为？我很困惑。给定的日期总是通过dateFromComponents创建的。

ios

objective-c

nsdateformatter

有奖征集｜云上CPU玩转AIGC挑战赛

参加活动赢取洛斐键盘、小米电纸书、智能音响等鹅厂周边！

回答 2

Stack Overflow用户

回答已采纳

发布于 2015-07-07 16:36:01

我的最后一个解决方案(我被藻类的回答推了一下)：

[dateFormatter setLocale:[[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"]];

Unicode规范是有用的(谢谢藻类)，苹果技术QA也是一样，它建议en_US_POSIX作为一种特殊的解决方案。

在iOS上，用户可以重写默认的AM/PM与24小时时间设置(通过设置>常规>日期和时间>24小时时间)，这会导致NSDateFormatter重写您设置的格式字符串，这可能导致您的时间解析失败。

最有帮助的是，我找到了惠兹对这种行为的解释，虽然有点老了：

当iPhone用户在“美国”和“法国”之间更改其区域格式时，用户的“24小时时间”设置将自动切换到该地区最常见的模式。在法国，这会将24小时的时间设置为“开启”，而在美国，这将使其“关闭”。然后，用户可以手动覆盖该设置，这就是问题的开始。问题来自于NSDateFormatter在用户手动选择的12或24小时时间模式中“卡住”。因此，如果一个法国用户手动选择12小时模式，并且应用程序请求NSDateFormatter以24小时格式“hhmm”输出时间，它实际上会收到12小时格式的时间，例如“01:00 PM”，就好像应用程序已经请求了“hhmm aa”一样。如果美国用户手动选择24小时模式，则会发生相反的情况:使用12小时格式“hhmm aa”输出时间实际上会使您得到24小时格式的时间，例如“17:00”。

票数 0

Stack Overflow用户

发布于 2015-07-06 23:11:25

我不相信该格式字符串能够生成包含您显示的am/pm注释的日期。如果我是您，我的第一个课程将是反复检查这些日期是否真的是由这些代码行生成的。

但是，如果您确信正在发生这种情况，那么我看到的唯一问题是，没有显式设置日期格式化程序对象的区域设置和日历可能是不正确的。日期格式语法是由unicode联合会定义的，管理规范在第4.5节中确实指出，“如果没有列出区域设置，则dayPeriods回退到AM/PM”。我不理解整个文档，但它表明，非常明确是最安全的途径。

如果您唯一的需求是ISO8601，那么您可以在UTC时区使用RFC3339，因为这是ISO8601的配置文件。这将为该格式创建正确的格式化程序：

let formatter = NSDateFormatter()
formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z"
formatter.timeZone = NSTimeZone(forSecondsFromGMT: 0)
formatter.calendar = NSCalendar(calendarIdentifier: NSCalendarIdentifierISO8601)!
formatter.locale = NSLocale(localeIdentifier: "en_US_POSIX")