The default json date format for the API is the "/Date(1326530063760)/" string. This is the default serialisation in .Net, which isn't beautiful and not what you'd describe as a 'common' standard.

For some objects returned from the API, there are additional fields called DateString and DueDateString, which are the same as the Date and DueDate fields, but serialised to a ISO-8601 formatted string (e.g. "2012-01-12T00:00:00"). There's a good writeup on Mark Emblings blog.

I think that, at some point, we're going to move towards using ISO-8601 format for all date times in Json, as this appears to be readable across many platforms.

I'm getting the same inconsistent "/Date(1326530063760)/" return values when using JSON, and it's been several months. It doesn't appear that this issue has been fixed. @Dan, that blog post by Mark Emblings is really useful in understanding this issue. Is this strange date format being introduced because the API servers are powered by .NET?

Can we rely on the *String fields as a substitute?

I'm using PHP and the *String can easily be parsed by strtotime(), but so far I'm getting strange dates when attempting to convert the "/Date(?)/" values.

Okay, after reading up on the "/Date(?)/" problem, I'm still left confused about the return values from Xero's API. The documentation says that all Date & Time values are UTC, yet I'm seeing values like: "/Date(1314100800000+1200)/", with a timezone offset (+1200) being specified. This makes it more difficult to convert it into a readable, correct format.

Recommendations? (other than just ignoring these fields and using the *String values)

I fixed this by extracting the numbers out of the date string, discarding the last three digits to get Unix time - allowing an easy conversation via date().

One cravat is the date strings ending in +XXXX. In my tests, these gave incorrect dates once I converted to UTC. The above solution should provide someone with a stepping stone if working with those dates.

It's quick, dirty and hardly elegant. An obviously more elegant solution is for Xero to pull their thumb out and fix it. I told them about this issue in my OP over two years ago now.

Hey, go easy guys. They are obviously a small team with limited resources. It's true that in today's climate not supporting a fully JSON API and failing to fix clearly incorrect choices like the date format (ever hear of ISO 8601?), is immensely frustrating as a developer. However, nasty invective is unlikely to move things along.

Xero, could you please assign some resources to providing and maintaining a complete JSON in/out API? XML is very hard to deal with compared to JSON, especially in JavaScript.