As noted in http://stackoverflow.com/q/23828573, the JSON serialisation format
for OffsetDateTime produces output such as "2014-05-16T07:28:51+02" (it uses
OffsetDateTimePattern.ExtendedIsoPattern).
However, ECMA-262 requires that the offset be specified including the minutes
(see http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15), and at
least Chrome fails to parse the string otherwise:
> Date.parse("2014-05-16T07:28:51+02")
NaN
> Date.parse("2014-05-16T07:28:51+02:00")
1400218131000
(The spec _also_ requires the milliseconds field, if present, to be three
decimals, rather than the six we generate. However, that appears not to cause
trouble in practice, so we might not want to change that.)
While JSON doesn't necessarily mean that you're parsing with JavaScript, it
seems reasonable to at least consider changing the serialization format to
always include the minutes.
Original issue reported on code.google.com by malcolm.rowe on 24 May 2014 at 9:04
The text was updated successfully, but these errors were encountered:
Fixed the Json.NET representation in revision a24b462035cd.
However, I've just tried this for the XML representation, and that has the same
issue - in particular, the conversion from XElement to DateTimeOffset fails
unless the offset is in HH:mm format.
It's unfortunate that we won't be able to round-trip values, but I think we
should change the XML representation too...
Original comment by jonathan.skeet on 30 May 2014 at 4:49
Original issue reported on code.google.com by
malcolm.rowe
on 24 May 2014 at 9:04The text was updated successfully, but these errors were encountered: