我通过以下方式启动了NSDateFormatter:
NSDateFormatter *dateFormatter = [NSDateFormatter new];
[dateFormatter setDateFormat:@"HH:mm:ss"];
在我的单元测试中,我现在检查格式化程序是否对于某些无效输入数据的行为是正确的,这些输入数据不匹配" HH:mm:ss "。 E.g:
NSDate *date = [dateFormatter dateFromString:@"10-31-01"]; // obviously not a time format in HH:mm:ss
我希望得到的NSDate为nil,因为字符串不应该与dateFormatter的模式匹配。
事实上,结果是:
Printing description of date:
2000-01-01 09:31:01 +0000
由于时区而偏移1小时,我想。但是我仍然不希望格式化程序返回无效输入的结果,并期望" nil":
XCTAssertNil(date);
以下格式的相同(意外)结果:
@"23-59-59" // (see format above)
@"23-59:59"
@"23:59-59"
格式化程序似乎将短划线解释为冒号,因此能够解释字符串。
Swift中的同样问题(参见短操场实现的图片)。
任何人都有一个想法,我是否错过了一个明确的设置,或者这是否是预期的,特别是赞赏的行为?
更新了Apple的错误报告
请注意我们的工程团队已确定此问题 根据所提供的信息行事。
似乎ICU的udat_parseCalendar()非常宽容且仍然如此 即使字符串与格式不完全匹配,也能够解析。 我们理解在这些情况下格式化程序更喜欢返回nil 但是(1)我们没有简单的方法知道输入字符串 与ICU允许的格式不匹配,并且不会抛出 错误和(2)在这些情况下突然返回零几乎 肯定是个比较问题。
- >不会修复,因为它不会抛出错误(它是容错的)并且更改可能会破坏正在运行的代码。