title: Parsing rfc3339 dates with NSDateFormatter in iOS 4.x and MacOS X 10.6: impossible?
body: <p>Parsing a rfc3339 date with NSDateFormatter appears to be impossible, in the general case. Am I wrong? [Edit 2 years later: there is now a way! See below and footnote.]</p>
  
  <p>A not-especially-malleable web service is feeding me dates like:</p>
  
  <pre><code>2009-12-31T00:00:00-06:00
  </code></pre>
  
  <p>Rfc3339 compliant, default output of the jaxb library they're using. Note the colon, which rfc3339 <strong>requires</strong> when the offset isn't a literal "z":</p>
  
  <blockquote>
  <pre><code>time-numoffset  = ("+" / "-") time-hour ":" time-minute
  time-offset     = "Z" / time-numoffset
  </code></pre>
  </blockquote>
  
  <p>I want to parse these into NSDates.</p>
  
  <p>NSDateFormatter wants patterns in the syntax specified by <a href="http://unicode.org/reports/tr35/tr35-6.html#Date_Format_Patterns" rel="noreferrer">Unicode</a>, which offers date field symbols for timezones like "PDT", "-0800", "GMT-08:00" but not "-08:00".</p>
  
  <p>Googling, and other similar SO questions, produces only date formats like</p>
  
  <pre><code>[myDateParser setDateFormat:@"yyyy'-'MM'-'dd'T'HH':'mm':'ssZ"];
  /* or: */ [myDateParser setDateFormat:@"yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'"];
  </code></pre>
  
  <p>The latter of which requires a literal "Z", and the former insists either the absence of a colon or presence of a "GMT". However, they appeared to work before ios 4.x (possibly by discarding the tz offset completely; my data aren't clear.)</p>
  
  <p>My options at this point are a sorry lot:</p>
  
  <ul>
  <li>discover some undocumented format specifier, or some strange mode to put NSDateFormatter into, that will accept the stray colon: longshot, likely nonexistent. [footnote]</li>
  <li>persuade my service publisher to turn all dates into zulu time and specify 'Z': politically challenging.</li>
  <li>write my own NSFormatter subclass or research good old <code>strptime_l</code>: work. :)</li>
  <li>string-manipulate my input and strip the last colon: brittle and ugly, but the likely path of least resistance.</li>
  </ul>
  
  <p>Have I understood the situation accurately, that current NSDateFormatter follows unicode strictly without extensions; and the unicode formats are insufficient to fully describe an rfc3339 date?</p>
  
  <p><strong>[FOOTNOTE]</strong> I come back to this three years later to tack on a small addendum: Unicode and Apple have added this feature to the format strings, as of iOS6/OSX10.8. Compare <a href="http://www.unicode.org/reports/tr35/tr35-25.html#Date_Format_Patterns" rel="noreferrer">The latest revision as of this writing</a> with <a href="http://www.unicode.org/reports/tr35/tr35-19.html#Date_Format_Patterns" rel="noreferrer">its immediate predecessor</a>, and note the addition of 5 "Z"s, which yields a zone format like "-08:00". So if you can get away with ditching support for 5.x/10.7, there's a new right way to do it. I'll leave the previous answer stand, as it's still the best approach when backward compatibility is required.</p>