Hello Everyone,
Is there a recognised best practices setup with respect to Platform Time Zone settings and what you code w/in a system.
I’ll assume that if our platform is set to local time across all instruments (where we live), that we should adjust the code to marry.
For example, AUS AEST (non-DST) will have DAX open of 1600 in Melbourne AUS during EU CEST (DST).
Here we could use as an example;
DEFPARAM FlatBefore = 1600 //No ANYTHING before 08:00 CEST – ALL Flat, Zero Open, Pending Limit or Stop Orders – No Trades before 08:00 CEST
or;
TimeForbidden = OpenTime < 160000 OR OpenTime > 060000 //No ANYTHING BEFORE 8.00 Open or AFTER 22:00 Close
Curious as to whether it’s better to roll with platform local time across all instruments, convert time or set them individually within the platform or go with ‘actual’ open and close times for example and whether there’s gotchas in going one way of the other.
I know this seems a little rudimentary but it’s work in progress alongside Daylight savings roll, sorting that will then also allow for a closer look at triple witching times.
Going slow here but still going!
Came across this with a quick google-fu, will have a gander but if there’s any specific gotchas, feedback from the community is always welcome.
https://www.prorealcode.com/topic/pro-order-automatic-trading-time-zone/
It’s really as they say in the thread. For the backtesting and automated trading module, you must work with the hours defined in your platform.
It’s a different case for the proscreener module, where you must work with the time zone of the market you are scanning.
Can I also ask a question please. With examples. I’m still trying to get my head around the timezone settings and reference it to what I see. I wish to have a universal rule base.
If I may use an example strategies and ticker (arbitrary for discussion)
Data provider: IG
Ticker: MTUM (iShares MSCI USA Momentum Factor ETF)
Timezone settings: ‘Use local timezone UTC -4’ & ‘Use trading hours for this market’
Strategy 1:
DEFPARAM CumulateOrders = False
DEFPARAM PreloadBars = 500
// Condition for 3 consecutive down days
downDays = Close[2] < Close[3] AND Close[1] < Close[2] AND Close < Close[1]
// Buy condition: 3 consecutive down days
IF downDays AND NOT LongOnMarket THEN
BUY 1 CONTRACT AT MARKET
ENDIF
// Sell condition: Close > previous day's high
IF Close > High[1] AND LongOnMarket THEN
SELL AT MARKET
ENDIF
Example 1:
Strategy rules:
- Buys at the next open after 3 down days.
- Sells when the candle close is higher than the prior high.
So, to my understanding;
- The timezone is now set to the NY market, daylight adjusted.
- The trading hours are set to the NY market, for when the ticker trades. 0930 -1600 hrs
What I expected:
- Backtesting trades should show position open and close at 0930
Confusion:
- When backtesting the orders are placed at 0000 (Outside of market hours)
Thanks in advance,
Please see attached pictures for reference.
Was there ever a solution to the issue of time zones and aligning with the underlying market’s official trading hours? I’m autotrading Nasdaq 100 CFDs (US Tech 100 Cash via IG Markets) and I want my strategy to only be active during official NYSE/Nasdaq market hours: 09:30–16:00 New York time, regardless of my local time zone (e.g., during daylight saving time in Europe).
I get identical backtest results whether I use the product’s default time setting or explicitly set the trading hours to 09:30–16:00 NY time, which suggests that this configuration doesn’t actually impact how the strategy runs.
JSParticipant
Senior
CFDs (IG) are not standardized like Futures (IB), where you can select between “Regular Trading Hours (RTH)” and “Extended Trading Hours (ETH)”…
CFDs are traded 24 hours a day, and the “Open” of a new day starts at 00:00…
Positions are always opened at the Open of the new bar, this means that if you’re trading daily charts on IG, any positions will be triggered at the Open of the new daily bar, which is at 00:00…
If you want to trade within specific hours instead of using the full 24-hour session, you’ll need to use intraday data and define the time window manually.
For example, to restrict trading to between 09:30 and 16:00, you can use:
Alternatively, to automatically flatten all positions outside of regular trading hours, you can set:
These conditions ensure your strategy only runs during your desired time window, mimicking regular market hours within a 24-hour CFD environment…
When implementing time zone management for trading systems, best practice is usually to normalize on **UTC** (Coordinated Universal Time) internally for uniformity across several time zones and instruments. This eliminates problems due to Daylight Savings Time (DST) and different local time zones. You can then convert to the appropriate local time zone (such as AEST or CEST) for display or particular trading rules. For example, you can utilize UTC for your fundamental system logic and only convert when needed for rules such as trade opening/closing hours. This will make your time-based conditions, such as “no trades before 08:00 CEST,” consistent and prevent confusion between markets. The trick is to maintain time-based logic and comparisons in a unified, default form (UTC) and to switch only upon representation or validation of particular times so that it works smoothly around DST changes and trading sessions.
You should go and spam elsewhere with your BS.
