I got a NSDateFormatter initiliased the following way:
NSDateFormatter *dateFormatter = [NSDateFormatter new];
[dateFormatter setDateFormat:@"HH:mm:ss"];
In my Unit tests I do now check, whether the formatter behaves the correct way for certain invalid input data that does not match "HH:mm:ss". E.g:
NSDate *date = [dateFormatter dateFromString:@"10-31-01"]; // obviously not a time format in HH:mm:ss
I would expect the resulting NSDate to be nil, as the string should not match the dateFormatter's pattern.
In fact, the result is:
Printing description of date:
2000-01-01 09:31:01 +0000
1 hour offset due to the timezone, I guess. But still I don't want the formatter to return a result for an invalid input and would expect "nil":
XCTAssertNil(date);
Same (unexpected) result for the following formats:
@"23-59-59" // (see format above)
@"23-59:59"
@"23:59-59"
The formatter seems to interpret the dash as a colon and is thus able to interpret the string.
Same problem in Swift (see image from short playground implementation).
Anybody got an idea, whether I am missing an explicit setting or whether this is expected and especially appreciated behavior?
UPDATED with Bug Report from Apple
Please know that our engineering team has determined that this issue behaves as intended based on the information provided.
It appears that ICU’s udat_parseCalendar() is very lenient and still is able to parse even if the string doesn’t exactly match the format. We understand preferring that the formatter return nil in these cases but (1) there’s no easy way for us to know that the input string doesn’t match the format since ICU allows it and doesn’t throw an error and (2) suddenly returning nil in these cases would almost certainly be a bincompat issue.
--> Will not be fixed, as it does NOT throw an error (it is rather error tolerant) and a change could break working code now.
