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

Hi,

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.

Thanks
Hi,

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?

Thanks.
 

W. Abdullah (Community Manager)  

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

I've just sent an email with some details.

Thanks
 

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..
 

Daniel 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.

Wakie
 

Ryan Wakefield