The price history endpoints are currently returning the wrong time for Sydney. For example:
https://demo-api.ig.com/gateway/deal/prices/CS.D.AUDUSD.CFD.IP
params = {'from': '2017-04-13T12:40:00', 'to': '2017-04-13T12:41:00', 'resolution': 'MINUTE_10'}
This should return a single 10 minute bar with a start time of 12:40 but instead returns:
{"prices":[{"snapshotTime":"2017/04/13 13:40:00","snapshotTimeUTC":"2017-04-13T02:40:00","openPrice":{"bid":0.75676,"ask":0.75682,"lastTraded":null}.....
The UTC time of 2017-04-13T02:40:00 is correct and corresponds to local time of 12:40. However it gives "snapshotTime":"2017/04/13 13:40:00" presumable because it does not take into account the fact daylight savings time ended a week ago.
Lucky the input times in the 'to and 'from' fields are correctly interpreted with the right local time and as long as you just use the returned UTC and ignore the local time this is not an issue, but it does effect the other price history endpoints which do not return UTC.
Ok this is now more broken than before.
{'from': '2017-04-24T16:00:00', 'to': '2017-04-24T16:02:00', 'resolution': 'MINUTE'}
Now returns time stamps between 17:00:00 and 17:02:00 Sydney time for both the "snapshotTime" and "snapshotTimeUTC". So although "snapshotTime" and "snapshotTimeUTC" now both agree with each other the API does not return the requested time interval but a time interval shifted 1 hour forward.
Trying to think of a way around this which wont break when its fixed and also wont chew through my data allowance (like requesting an hour either side of the desired interval then throwing away unwanted data-points).
Also dreading going through my dataset and repairing all the damage this has caused.
I think one way to work around this is to first request a single datapoint, use this to determine any DST offset effecting the API, then adjust the subsequent call when you fetch the actual data that you want. This wastes an api call but only wastes 1 datapoint and prevents your code being bamboozled by strange DST behavior in the API. I would also recommend only using the returned UTC despite the fact that it now seems to agree with the local "snapshotTime", who knows if it will still agree next time Sydney changes over to DST.