Building a systematic system part one - data capture

volpunter said:
Systematic trading is only around for less than 10 years you tool.
More...

and no, systematic trading has been around for more than 10 years, you are simply trying to hijack that term because your generation has nothing to show in terms of accomplishment, above all with all the controversy around HFTs and the obscurity of market manipulation with electronic trading.

and you are revealing your lack of experience and exposure in the industry with that claim. When did you graduate ? 2001 ? lol

for anyone who has been in the industry long enough, systematic trading was already there. I have worked on systematic trading projects as early as 1993, and I am sure others have worked on some before that.
 
Very interesting thread.


If you trade a foreign futures whose primary exchange is in a different time zone, how do you deal with the different trade hours, the different holiday schedule?
 
You should always always unify time stamps especially when you trade at exchanges in different time zones. Most professionals use UTC. Then in your static data repository or wherever you store static data such as exchange hours or holiday schedules you also convert schedules according to UTC. IF you adhere to this basic concept then you will hardly ever make a major mistake regarding time zones.

Obviously your machine instance on which you run your architecture should also run in UTC or whatever other base zone you decide it to be.

curiousGeorge8 said:
Very interesting thread.


If you trade a foreign futures whose primary exchange is in a different time zone, how do you deal with the different trade hours, the different holiday schedule?
More...
 
Last edited:
curiousGeorge8 said:
Very interesting thread.


If you trade a foreign futures whose primary exchange is in a different time zone, how do you deal with the different trade hours, the different holiday schedule?
More...

From the post

"So I limit my sampling to active opening times in markets, although I don't account for changes in daylight savings. I will try and get prices on holidays (unless I've turned my system off on a “universal” holiday to do some maintenance). "

So its the laziest possible option. If you want to do more work you can adjust the "active" times for changing daylight savings, and also maintain a holiday calendar for each market. As its is I can't distinguish between (a) not being able to get a price because there is insufficient liquidity (no tick updates in the given period), (b) the market being closed due to a holiday, (c) the market closed because daylight savings has pushed my normal collection time into the market being closed. I don't lose any sleep over these differences.
 
Thanks, globaltrader. Unfortunately I trade on much shorter time frame (a few days) and have to be precise with the calendars that different exchanges are associated with.
 
volpunter said:
You should always always unify time stamps especially when you trade at exchanges in different time zones. Most professionals use UTC. Then in your static data repository or wherever you store static data such as exchange hours or holiday schedules you also convert schedules according to UTC. IF you adhere to this basic concept then you will hardly ever make a major mistake regarding time zones.

Obviously your machine instance on which you run your architecture should also run in UTC or whatever other base zone you decide it to be.
More...

Good advice. That is what I am trying to do but I feel I spend too much time worrying about daylight time changes, early close of different markets, etc.
 
Yeah me too. It's a good one. Everyone knows that an ATS reacts to events, not asks for what just happened... well, almost everyone.
 
You must log in or register to reply here.
Back
Top