Update
As of iOS 7, NSDateFormatter does indeed create an NSDate when presented with a string in this format:
NSDateFormatter *formatter = [NSDateFormatter new];
[formatter setDateFormat:@"@"yyyy'-'MM'-'dd'T'HH':'mm':'ssZ""];
NSLog(@"non–nil date, even honoring the 7–minute–offset in the time–zone on iOS 7: %@",
[formatter dateFromString:@"2011-07-12T18:07:31+02:07"]);
For iOS 6, the answer is to not use an NSDateFormatter…
Okay, up to this point I have read
- the Docs and
- Technotes at Apple,
- the important part of the Unicode reference and
- quite a few questions and answers here
regarding how to use NSDateFormatter
in order to create an NSDate
out of a string.
I have stumbled upon Peter Hosey's ISO8601DateFormatter, as well.
Looking into his implementation, I wonder:
Isn't there a way that is both correct and sane to get a string like this one 2011-07-12T18:07:31+02:00
into an NSDate
?
- It would be no problem if the last colon was missing.
- It would be no problem if there was a
GMT
prefixing the "+"-sign, but... - that is not the case.
I can hack it to work for my application (using the format @"yyyy'-'MM'-'dd'T'HH':'mm':'ssz':'00"
) but that is — of course — incorrect because it will discard the minute-information of the timezone.
I could also replace the last colon with an empty string, but I would consider that a hack as well.
So, is there some secret sauce to make NSDateFormatter
take that string from above and give me a valid and correct NSDate
?
Aside:
I have somewhere found the tip, that one could use +[NSDate dateWithNaturalLanguageString:]
to achieve my goal. This — however — only sets the date, but not the time! (Well it does set the time, but only taking the timezone-offset into account and not the HH:mm:ss part...)