From our research notebook

News, Time and Session Filters: Small Rules, Large Effects

We explain how apparently small requests about news and trading hours led us to define clocks, boundaries and the treatment of open positions.

“Avoid news” or “trade only this session” often arrived as a short addition to a larger brief. Working through those requests showed us how many decisions were contained in that sentence, starting with whose clock the system should follow.

We put every time on a defined basis

Broker server time can shift, and regions do not all change daylight saving on the same date. We identify the internal time basis and the conversion to sessions and calendar events. Otherwise, the same visible setting can refer to a different market window.

We decided what the filter was allowed to change

Blocking a new entry is different from closing an existing position. We keep that authority explicit, along with start and end boundaries, overnight sessions and late ticks. For news, the questions also include relevance, event importance, revisions and unavailable calendar data.

We looked at which trades the filter removed

We compare filtered and unfiltered behaviour on the same observations and inspect the excluded opportunities. We also examine clock changes and missing-data cases. This lets us discuss the actual effect of the rule instead of treating an extra switch as evidence of better trading.

Explore the technical detailOpen the full method, worked examples and implementation questions. We have kept this material here so you can follow the reasoning as far as you need.

“Do not trade around news” and “trade only during this session” sound like small additions. In software, each sentence opens a chain of decisions: whose clock, which event importance, what happens at the boundary, and whether existing positions are managed differently from new entries.

These filters can change the sample of trades, the market regimes seen by a strategy, and its behavior across brokers. Their value therefore comes from precision and testing, not from the comforting presence of another on/off switch.

Engineering note · ENG-10

A filter is a permission service

The entry module receives a decision, not a collection of ambiguous clocks.

  1. 01
    NormalizeConvert server, UTC, local, session, and event times with daylight-saving rules.
  2. 02
    ClassifyDetermine session state, event priority, blackout window, and data freshness.
  3. 03
    PermitReturn allow, block-new-entry, or a documented failure state.
  4. 04
    RecordLog the source time, rule, boundary, and effect on the strategy decision.

One timeline

Broker server time is not a permanent timezone. Some brokers shift it seasonally, and different regions change daylight saving on different dates. The filter needs one internal time basis and explicit conversion rules for trading sessions, user inputs, and calendar events.

Define the boundary

A window needs inclusive or exclusive start and end rules, day-of-week handling, weekend gaps, overnight sessions, and a policy for a tick that arrives after the boundary. News filters also need event priority, affected currency, before/after duration, revisions, duplicates, and a response when calendar data is unavailable.

Separate entries from positions

Blocking a new signal is different from closing or modifying an open trade. Unless the strategy explicitly assigns that authority, an operational filter should not silently replace the original exit logic. The safest default during uncertain calendar data is normally to follow a documented policy rather than inventing a state.

Measure the effect

A filter changes which trades remain in the sample. Test the base strategy and the filtered version on the same data, inspect the removed trades, and include clock changes and missing-data cases. A cleaner equity curve with very few remaining trades may be a selection effect rather than a robust improvement.

  • Use one internal timezone and explicit conversions.
  • Treat session and news boundaries as test cases.
  • Define the unavailable-calendar policy.
  • Keep entry permission separate from exit authority.
  • Report how many trades each filter removes.

Questions you may have

Should an EA close trades before scheduled news?

Only if that behaviour is part of the declared strategy or risk mandate. A news filter that merely controls entries should not silently become an exit system.

Is broker time the same as local market time?

No. Broker server time can use a different offset and may change seasonally, so session rules need explicit conversion and testing.

POLARIS / R21

Make time a testable permission rule

Scroll the diagram horizontally or open it at full size.

Make time a testable permission rule
Educational design example — values and states are not live performance.

Example clock: server UTC+2. Window: [14:25, 14:35).

Existing positions follow a separately stated management rule.

Open full diagram ↗

Evidence in practice

Make time a testable permission rule

Assume a session is allowed from 22:00 to 02:00 UTC, including the start and excluding the end. The broker changes from UTC+2 to UTC+3 on its daylight-saving schedule. The trading rule remains anchored to UTC; displayed server times change.

Overnight session across a server-time change
UTC event Server at UTC+2 Server at UTC+3 New entry permission
21:59:59 23:59:59 00:59:59 Blocked
22:00:00 00:00:00 01:00:00 Allowed
01:59:59 03:59:59 04:59:59 Allowed
02:00:00 04:00:00 05:00:00 Blocked; existing exit management continues

Calendar events carry provider ID, original and revised timestamp, importance, currency, retrieval time and data age. A duplicate ID is ignored. A revision replaces the future schedule and is logged. A stale feed or failed refresh blocks new entries when news permission is required; it does not disable protective exits. A late tick after the boundary uses current permission, not the tick time the EA hoped to receive.

To measure filter effect, replay the same strategy on the same tick data twice, changing only the frozen permission stream. Deleting trades from a finished report does not reproduce delayed signals or changed position paths. The public row data contains 7 exact time/session labels and 3 news labels; they can overlap. An older article selection of 13 uses an unpublished broader scope and cannot be reconstructed from those tags alone.

What to verify

  • Test an overnight session, both boundary inclusivity choices and the broker’s clock change.
  • Replay stale, duplicate and revised calendar events plus a late first tick.
  • Keep entry permission, management of open positions and emergency exits as separate authorities.

Limits of this example

This example uses a UTC-anchored policy. A broker-session policy is also possible, but its clock and daylight-saving source must be explicit.

Research quality record

Editorial ownership and primary references

Reviewed by POLARIS Research

Evidence scope

This article combines official platform behaviour with recurring, anonymized implementation patterns. Exact trading rules and client material are excluded.

Primary references

These references support platform behaviour or research concepts. They do not validate POLARIS performance and do not guarantee future results.

Related research and applications

Explore the next relevant layer

Move between focused research, system engineering and portfolio construction without losing the context of this page.

Why more trading filters do not always help →Risk controls inside every Expert Advisor →

Related research