Xero - beautiful accounting software

Xero Developer Help Center

Xero Developer Community

Community > API Endpoints >

Listing invoices returns weird DateTimeUTC

Started by Ryan Wakefield -   in API Endpoints


When I list invoices I get weird dates like this:
[DateTimeUTC] => /Date(1326530063760)/
[UpdatedDateUTC] => /Date(1326480130277+1300)/

Yet other examples in the same feed look like this:
[DateString] => 2012-01-12T00:00:00

Is there a reason for the inconsistency? How would I convert /Date(1326530063760)/ into a date that is more meaningful? I am using PHP.


Are you using one of these php sample code or your own?

Also it would be great if you can tell us the name of your application that you registered on https://api.xero.com so we can check its logs

W. Abdullah (Community Manager)  

Hi Welli,

I am using this https://github.com/thinktree/PHP-Xero.

The API Thumbprint is 42F12789A5FEE94FD583122E0AF08BFA737863AF.

Ryan Wakefield  

Hmmm, that's weird.

I just ran the thinktree code in localhost and all looks normal.

Did you say it it happened to some while the others are fine?

Can you e-mail us the application name and details to network@xero.com?


W. Abdullah (Community Manager)  

"DateString" returns the correct format, but "DateTimeUTC" and "UpdatedDateUTC" do not.

I've just sent an email with some details.


Ryan Wakefield  

We've identified a bug with responses in Json format that shows DateTimeUTC and UpdatedTimeUTC as UTC seconds.

We'll investigate this but in the meantime please choose xml format for responses.

W. Abdullah (Community Manager)  

Hi Wakie,

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.


Dan Barratt (Xero Staff)  

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.

Ted Wood  

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)

Ted Wood  

I believe the only recommendation thus far is to use the XML output. I don't accept this as a good enough solution and would have expected this issue to be resolved by now.

Ryan Wakefield  

This thread is somewhat old, yet I see the JSON api still gives /Date(...)/ strings.

Any updates?

Matthew Schinckel  

Is there a timeline for when this will be updated to ISO-8601?

Sam Barnett  

The format appears to be ms which is bizarre

As a loose example, looking at /Date(1326480130277+1300)/ from the OP

Drop the timezone off, and div by 1000 - date("Y-m-d H:i:s", 1326480130277 / 1000)
It appears to give the right result (bar any in-correctness for lacking time-zone)

These formats are common in JS, and also trivial to deal with
alert(new Date(1326480130277+1300)) works as expected.

But PHP really has no inbuilt/native/nice way of dealing with these response formats.
Infact the only practical way I see forward would be regex..which feels rather unnecessary and bloaty

This thread is over 2 years old now... and nothing appears to have changed?

Warren Strong  

I'm surprised that Xero devs are not more active in these community discussions. It would be really helpful to have their input and feedback.

Ted Wood  

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.


Ryan Wakefield  

Three and a half years later, and still this has not been addressed. Could we please have ISO dates ASAP?

Lawrence Dol  

i am facing same Issue but I am using salesforce Apex language. Please suggest.

Dependra Singh  

More than 4 years to get this fixed!?

C'mon Xero Devs, this is crazy.

"Just use XML is not an answer."

Please address this issue!

Ryan Marshall  

Xero obviously don't give a crap about developers.

Ryan Wakefield  

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.

While you are at it, how about OAuth 2.0?

Pretty please?

Lawrence Dol  

8 years later, and we still have to convert strings like /Date(1606780800000+0000)/ to a sensible date format... :(

Adam Reis  

@LawrenceDol you got your wish with OAuth 2... progress! I get the impression the API team has had a big boost from the developer evangelists which have been added in recent years – it's good to see.

For the OP @RyanWakefield – hopefully, you've switched to the excellent XeroPHP library which we've since adopted at Syngency, and outputs everything date-related as a PHP DateTime object :-)


Ryan Marshall  

We are using the NodeJS library, and no, it doesn't format everything date related into a JavaScript date object unfortunately.

/Date(1606780800000+0000)/ is supposed to be midnight on Dec 1st 2020 in NZ time, yet the timestamp passed from Xero corresponds to Dec 1st 2020 13:00 NZ time...

Adam Reis  

Storing/returning any internal date in anything but UTC is crazy, I agree.
They're apparently not taking DST into account either?

@XeroAPI devs – a simple fix would be to add `_utc` suffixed fields for all date objects, formatted as ISO 8601. Hopefully then the legacy .NET date fields can be deprecated/removed. I've not seen this anywhere else, and for an API as widely consumed as Xero's, it's madness.

Ryan Marshall  

Still need to use xml in 2021 ????

Syaginkumar AG  

To answer original question:

realDateUTC = 1 January 1970 + 1326530063760 ms = 14/01/2012 08:34:23

Time here is Unix Time, which is simply a number of seconds (or milliseconds in this case) that has passed since the beginning if Unix epoch.


Alex Soul