[Build 117] Extend SQ to allow time stamping in Data Download from Dukascopy

Hi Mark,



thanks for providing some attention to this issue in the entry "Allow no mess-up with time zones on data import". You marked it as refused, but I suppose you are still interested to extend SQ with a feature to allow time stamping when downloading the data through SQ.


Let me address your questions:


Regarding what Tickstory makes to data,  I will to explain you concerning the time settings I used and that I referred above. After years dwelling with this problem (broker server time zone, DSTs, etc) I came to the conclusion it is of a huge advantage to restrict the brokers you work with to the ones which have GMT+2/+3 server time. 


The above means that I only consider in my trading brokers that:


- in winter time have no DST implemented and have server time with GMT+2 and 
- in Summer implement DST (and remove DST) at the same dates as it happens in New York (not London for instance)


This allows that, whatever the date of the year, my trading week ends always at 23:59:59 also assuring a full trading week in my chart and this time is exactly always the end of the Friday's NY session. With this choice I also have the advantage to avoid any doubts about what time is what in my trading charts, any time of the year. I've gained a big deal of convenience  by adopting GMT+2/+3 brokers only and I am very strict about it.


This means that when I want to test strategies (made with SQ or EA wizzard) that have some kind of dependency to time I must be 100% absolutely sure about the time stamping of my data. This is crucial. Then, for longer timeframes like H4 or daily, is also crucial that you are sure you have full candles in a week (and not a H4 candle split in half between Friday and Sunday for instance). 



This is why tools that download the data without making some kind of time adjustment (in my case, and for the reasons above, data 100% synchronized with my GMT+2/+3 broker server time) are not a valid option to me and quite frankly I don't understand how can traders work with data in which one is not sure about the time that correspond to each candle, all things considered (timezone, DST, full or partial candles per week of trading etc.).


So regarding Tickstory, what I suppose they do (in option I use: "EST +07:00 / New York Trading Hours") is the following:


- Keep track of the dates when DST is implemented (March to be valid during summer) and removed (in October/November)
- On these exact dates Tickstory adjusts the time stamping of each tick (GMT+2 in October/November when DST in New York city is removed and GMT+3 usually in March when DST is implemented in NY City)
- Of course they need to know what time comes from Dukascopy in the first place (I have no idea about that, as I am at the receiving end of Tickstory)
- Downloaded data becomes 100% synchronized with your GMT+2/+3 broker, trading weeks are always full weeks from 00:00 Monday to 23:59:59, with 5 full daily candles and 30 full H4 candles in a trading week. If you want to compare a backtest with your broker data, the time of each candle is exactly the same between broker and BT data, regardless of the time of the year- BIG Advantage!
- I suppose they do exactly the same with other brokers/Server time schemes and apply local DST (meaning the DST dates enforced in the city mentioned in the settings dialog, when applicable). I am not interested in these other options as, as I've told you above I see huge advantages of a GMT+2/+3 (NY DST) broker and the same scheme for data, so I dont use any other time stamping than "EST +07:00 / New York Trading Hours", which assure me a GMT+2/+3 (with NY DST) time stamped data.


Important to not also that when I started to use this option at Tickstory I made tests in several parts of the year in several years, including the periods when DST is not synchronized between London and NY (usually some days or a couple of weeks) and could verify that my data would always match my broker data, with the same time stamping.


About what I do to download the data from Tickstory, I wrote an Article sometime ago about it and I share it here. In there, at the end, I think you can find the information you need.


Thanks for the attention and willingness to improve the tool.











Attachments
No attachments
  • Votes +2
  • Project StrategyQuant X
  • Type Feature
  • Status Fixed
  • Priority Normal

History

l
#1

Blade Runner

12.07.2018 16:59

Task created

l
#2

Blade Runner

12.07.2018 17:01

Attachment DST_Article.pdf added

l
#3

Blade Runner

12.07.2018 17:06
Just a quick correction. 


When you trade a strategy in which you need to have as a reference the London open time (as an example), naturally you cant work with data that implements/adjusts to the New York DST as only by coincidence the DST will be implemented and removed in each year at the same dates in both cities. For such cases, I use a GMT+2/GMT+3 option in Tickstory but with DST from London (also explained in the end of the PDF file I attach).

MF
#4

Mark Fric

26.07.2018 14:30
thank you for the detailed explanation. We'll not make it into the next build, but we'll try to do it into the one after that (108).
m
#5

mikeyc

19.09.2018 18:39
Voted for this task.
HH
#6

Hans

20.12.2018 14:05

Voted for this task.


However, I would not confine it to above-mentioned brokers (GMT + 2 / + 3 server time), but rather make the data import so flexible that tick data to be imported finally matches the timzone of the broker used. (Selection via DropDown or editable data field)

MF
#7

Mark Fric

17.01.2019 10:52

Status changed from New to Fixed


Votes: +2

Drop files to upload

or

choose files

Max size: 5MB

Not allowed: exe, msi, application, reg, php, js, htaccess, htpasswd, gitignore

...
Wait please