Jump to content
  • 0

Daily histrorical data - interpretation of UTC (?) date stamp and daylight savings


smx01

Question

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

Quote

 

Response from IG REST API

{'prices':                         bid                             ask                         spread                  last                         

                       Open    High     Low   Close    Open    High     Low   Close   Open High  Low Close  Open  High   Low Close Volume

DateTime                                                                                                                                 

2019:10:04-00:00:00  221.72  223.35  215.64  222.62  223.72  225.35  217.64  224.62    2.0  2.0  2.0   2.0  None  None  None  None  24155

2019:10:05-00:00:00  222.63  224.51  217.35  220.59  224.63  226.51  219.35  222.59    2.0  2.0  2.0   2.0  None  None  None  None  15863

2019:10:06-00:00:00  220.58  222.86  217.54  219.96  222.58  224.86  219.54  221.96    2.0  2.0  2.0   2.0  None  None  None  None  19415

2019:10:06-23:00:00  219.94  229.79  214.72  228.05  221.94  231.79  216.72  230.05    2.0  2.0  2.0   2.0  None  None  None  None  33125

2019:10:07-23:00:00  228.06  238.31  228.05  231.62  230.06  240.31  230.05  233.62    2.0  2.0  2.0   2.0  None  None  None  None  32501, 'instrumentType': 'CURRENCIES', 'allowance': {'remainingAllowance': 9992, 'totalAllowance': 10000, 'allowanceExpiry': 602836}}

 

And here's what it looks like around April-5 2020

Quote

 

Response from IG REST API

{'prices':                         bid                             ask                         spread                  last                          

                       Open    High     Low   Close    Open    High     Low   Close   Open High  Low Close  Open  High   Low Close  Volume

DateTime                                                                                                                                  

2020:04:02-23:00:00  225.78  248.33  224.26  236.75  227.78  250.33  226.26  238.75    2.0  2.0  2.0   2.0  None  None  None  None  106597

2020:04:03-23:00:00  236.81  238.76  229.59  234.14  238.81  240.76  231.59  236.14    2.0  2.0  2.0   2.0  None  None  None  None   47901

2020:04:04-23:00:00  234.15  241.81  233.12  235.39  236.15  243.81  235.12  237.39    2.0  2.0  2.0   2.0  None  None  None  None   59462

2020:04:06-00:00:00  235.37  245.53  224.56  243.58  237.37  247.53  226.56  245.58    2.0  2.0  2.0   2.0  None  None  None  None   65707

2020:04:07-00:00:00  243.57  264.96  241.44  258.13  245.57  266.96  243.44  260.13    2.0  2.0  2.0   2.0  None  None  None  None   84988

2020:04:08-00:00:00  258.14  279.18  245.70  259.45  260.14  281.18  247.70  261.45    2.0  2.0  2.0   2.0  None  None  None  None  103281

2020:04:09-00:00:00  259.48  273.91  252.52  261.94  261.48  275.91  254.52  263.94    2.0  2.0  2.0   2.0  None  None  None  None   95054

2020:04:10-00:00:00  261.95  262.39  231.19  235.09  263.95  264.39  233.19  237.09    2.0  2.0  2.0   2.0  None  None  None  None   97915, 'instrumentType': 'CURRENCIES', 'allowance': {'remainingAllowance': 5197, 'totalAllowance': 10000, 'allowanceExpiry': 253266}}

 

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.

Link to comment

5 answers to this question

Recommended Posts

  • 0

Hi Steven, I just found this because I was looking up about daylight saving. 

The English have British Summer Time BST which is UTC+1, so the market adjusts. It also reverts back to UTC+0 when it goes back in time. 

Daylight saving also occurs in NY, so they too move forward in Summer by 1 hour and back in Winter. 

Personally it does my head in, especially when my timezone doesn't change. 

Link to comment
  • 0
30 minutes ago, majicktrader said:

Hi Steven, I just found this because I was looking up about daylight saving. 

The English have British Summer Time BST which is UTC+1, so the market adjusts. It also reverts back to UTC+0 when it goes back in time. 

Daylight saving also occurs in NY, so they too move forward in Summer by 1 hour and back in Winter. 

Personally it does my head in, especially when my timezone doesn't change. 

Every programming language has a core method to convert datetimes to local times.

Python: https://stackoverflow.com/questions/4770297/convert-utc-datetime-string-to-local-datetime

c#: https://docs.microsoft.com/en-us/dotnet/api/system.timezoneinfo.converttimefromutc?view=netcore-3.1

You don't have to deal with time zones yourself. 

  • Sad 1
Link to comment
  • 0
On 14/10/2020 at 17:50, majicktrader said:

The English have British Summer Time BST which is UTC+1, so the market adjusts. It also reverts back to UTC+0 when it goes back in time. 

Daylight saving also occurs in NY, so they too move forward in Summer by 1 hour and back in Winter. 

Personally it does my head in, especially when my timezone doesn't change. 

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 :)

Link to comment
  • 0
On 14/10/2020 at 18:24, jlz said:

Every programming language has a core method to convert datetimes to local times.

Python: https://stackoverflow.com/questions/4770297/convert-utc-datetime-string-to-local-datetime

c#: https://docs.microsoft.com/en-us/dotnet/api/system.timezoneinfo.converttimefromutc?view=netcore-3.1

You don't have to deal with time zones yourself. 

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. 

Edited by smx01
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • image.png

  • Posts

    • As the cryptocurrency space evolves, Bitget keeps bringing up worthwhile initiatives to make crypto trading interesting and easy for its users as well as helping them maximise profit.  Gleaning from the likes of Candybomb to PoolX and the likes, the CEX has been seen to steadily provide these services. The PRE MARKET trade seems to be the newest product on the block right now. It is an over the counter trading platform that specialises in providing a pre-traded marketplace for new coins before official listing.  Simply put, it is a p2p framework of some sort that facilitates trading between buyers and sellers enabling them to acquire coins at optimal price thus enhancing advance liquidity and complete delivery at a mutually agreed upon time.  The interesting thing about the Pre Market is that; it allows the advocates or supporters of newly launched projects to trade through a contract before the token goes mainstream or before being airdropped.  This framework is very good for projects that have very high speculation, speculative traders should check out this product.  Good thing is the Pre trade is already live, you can leverage on it to purchase $MERL before its official listing, you could get to earn massive ROI. Here's the link; https://www.bitget.com/pre-market/MERLUSDT
    • Atomic Wallet is experiencing issues with their staking and rewards, so I would like to transfer my ATOMs to another crypto wallet. I contacted Atomic Wallet Support and they recommended Cosmostation Wallet and gave me instructions on how to do this. I followed the links they sent me, which required me to fill in my seed phrase. My ATOMs transferred to Cosmostation Wallet but were immediately transferred out. I never made that transaction. I contacted Cosmostation Wallet Support and asked them what happened. They informed me that I must have been talking to a scammer posing as support from Atomic Wallet. I contacted Atomic Wallet and they said I wasn't talking to a scammer and those links are legit. I lost my funds because my PC must be infected. Atomic Wallet wouldn't outright scam me would they?  
    • With the recent surge in "Cat Coins," a wave of playfulness and intrigue is sweeping the crypto community. KHAI, a meme token built on the Solana blockchain, is at the forefront of this movement. Fueled by a bullish community sentiment, KHAI has experienced a staggering 15.27% price increase in the past 24 hours, pushing its market cap to a noteworthy 24.4 million dollars. This impressive growth comes on top of a remarkable 94.3% price jump over the past week, significantly outperforming both the global market and other Solana-based cryptocurrencies. Could KHAI be the next big memecoin to reach unprecedented heights? Its recent listing on the Bitget exchange, accompanied by a giveaway event, certainly adds fuel to the fire. However, the question remains: will this newfound attention propel KHAI to even greater heights, or will it succumb to the volatility often associated with memecoins? Only time will tell.
×
×
  • Create New...
us