Jump to content

smx01

Community Member
  • Posts

    4
  • Joined

  • Last visited

smx01's Achievements

New Contributor

New Contributor (1/10)

0

Reputation

  1. Is anyone from IG available to answer this query definitively, once and for all?
  2. Thanks Jlz. I've used the arrow lib, it's excellent. My assumption is that the timestamps coming out of IG are UCT. So I translate the UCT to my local time zone (Melbourne, Aus). My confusion is more around my previous response, why does the UCT time shift change, if it's UTC. It must be because ultimately that UCT is based on some other timezone.
  3. Thanks. But why does IG do this? UTC is universal, its a fixed notion of time. UTC itself shouldn't/doesn't change because of daylight savings etc. Is it the case that IG 24 windows are timed according to a fixed local time in London? Or Sydney? And therefore the UCT changes? Still confused
  4. Hi everyone, I am working to download historical daily data via the REST API (crypto EPICs mainly - e.g. CS.D.BCHUSD.CFD.IP). I believe the timestamp that comes with the data us UTC. I am finding that for the period where AEST is in daylight savings time (DST), e.g. Oct-6-2019 - Apr-5-2020, the date stamp changes. Here are two corresponding transitions: Here's what the REST API looks like around Oct-6 And here's what it looks like around April-5 2020 So two questions: 1. Why does this happen? UCT is UCT - 00:00:00 corresponds to the start of the day for a 24 hr period. I don't know why it would shift just because we're in DST in AEST. Is it that the actual reference point for a 24 hr period is 10am -10am AEST, and when DST starts, the UTC adjusts? And then the actual daily/24hr data then 23:00:00 UCT to 23:00:00 UCT? 2. So you end up with dates within DST shifted by 1 day, which can be fixed post-REST-API - but is there another way to deal with this within the API itself? Thanks for any advice... Steven.
×
×
  • Create New...
us