Updates to the API

8 posts / 0 new
Last post
Updates to the API

Hi all,

As of this weekend, the following changes will come into effect:

The field CreatedDate for all Orders will be in UTC time instead of your time zone.

The field GoodTillDate specified in Working Orders will now be accepted and returned as UTC time.

There is also now an option to submit the GoodTillDate value as a Unix timestamp in milliseconds, in addition to the existing String date format.

Note: Unix timestamps have no concept of time zone adjustments and is defined as the number of seconds/milliseconds that has elapsed since 00:00:00 UTC, 1st January 1970.


Can you give CreatedDate or

Can you give CreatedDate or an extra field like CreatedDateTimestamp in a Unix Timestamp format? That would be a lot easier than us having to take a UTC time and try convert it for the user.

Sounds good. I assume that

Sounds good. I assume that the documentation for GET /workingorders, POST /workingorders/otc, and PUT /workingorders/otc/{dealiId} will also be updated?

Will CreatedDate be included?

I agree with Steveyboy in that a CreatedDate would be far more beneficial than having to convert UTC time.

Also, giving us notice on Friday at 1pm doesn't give us enough time to fix things for Monday.

I do wish the IG API team would consider the impact of their changes and give us reasonable notice.

GET /workingorders now

GET /workingorders now returns createdDate in UT as a string:

"createdDate": "2015/06/29 11:42:28:000"

But, GET /history/activity (and many other API "functions") still uses the client's local time:

"date": "29/06/15",
"time": "13:42",

I think you have to either:

1) use only Unix Timestamp format for times given in UT, or
2) rename the field so that it is self-explanatory, e.g., createdDateUTC instead of createdDate, or
2) explicitly include the timezone in all yyyy-mm-dd hh:mm... dates/times, or
4) use UT only (Unix Timestamp preferred) in the entire API.

Giving date/time in string format using a mix of implicit timezones will cause endless confusion. My own preference would be option 4, but I can live with anything that is consistent (and correct, obviously).

Also, shouldn't these changes

Also, shouldn't these changes really go into new versions of the "functions" rather than changing the behaviour of what people are already using?

GET /workingorders now

Hi APITrader,

We are aiming to have all this resolved in the next few weeks. Unix timestamps have been chosen as a sensible option and to make this consistent throughout the API.


Unix timestamps throughout

Unix timestamps throughout the API sounds excellent! Thanks!

Log in or register to post comments