Dans notre carnet de recherche

Filtres d’actualité, d’heure et de session : petites règles, grands effets

Nous montrons comment de petites demandes sur les horaires ou les annonces ouvrent des choix sur les horloges, les limites et les positions ouvertes.

« Éviter les annonces » semblait une courte addition. Son développement nous a montré combien de décisions elle contient, à commencer par la référence horaire.

Nous choisissons une base temporelle

L’heure serveur peut varier et les changements saisonniers ne coïncident pas partout. Nous définissons la conversion vers les séances et événements pour préserver le sens du réglage.

Nous définissons le pouvoir du filtre

Bloquer une entrée n’est pas fermer une position. Nous précisons frontières, séances nocturnes et ticks tardifs. Les annonces ajoutent pertinence, importance, révisions et absence de calendrier.

Nous examinons les opérations retirées

Nous comparons avec et sans filtre sur les mêmes observations, en inspectant occasions supprimées, changements d’heure et données manquantes. Nous discutons ainsi de son effet réel.

Explorer les détails techniquesOuvrez la méthode complète, les exemples et les questions de mise en œuvre. Nous conservons ces éléments pour vous permettre de suivre le raisonnement aussi loin que nécessaire.

Ces filtres doivent définir une horloge, des limites inclusives, les changements d’heure et leur autorité sur les positions déjà ouvertes.

Bloquer une nouvelle entrée n’autorise pas automatiquement à modifier ou fermer une position existante.

Analyse technique POLARIS

Filtres d’actualité, d’heure et de session : petites règles, grands effets

Bloquer une nouvelle entrée n’autorise pas automatiquement à modifier ou fermer une position existante.

  1. 01
    Utiliser une chronologie canoniqueL’heure serveur peut changer par saison ; les sessions et événements sont donc convertis depuis une base interne unique.
  2. 02
    Définir chaque frontièreDébut, fin, jours, nuit, premier tick tardif, priorité de l’événement et indisponibilité du calendrier deviennent des cas de test.
  3. 03
    Mesurer l’effet de sélectionLa stratégie de base et la version filtrée sont comparées sur les mêmes données, avec le nombre et le type de trades supprimés.

Utiliser une chronologie canonique

L’heure serveur peut changer par saison ; les sessions et événements sont donc convertis depuis une base interne unique.

Définir chaque frontière

Début, fin, jours, nuit, premier tick tardif, priorité de l’événement et indisponibilité du calendrier deviennent des cas de test.

Mesurer l’effet de sélection

La stratégie de base et la version filtrée sont comparées sur les mêmes données, avec le nombre et le type de trades supprimés.

Les questions que vous pourriez vous poser

Quel est le contrôle le plus important ?

La stratégie de base et la version filtrée sont comparées sur les mêmes données, avec le nombre et le type de trades supprimés.

Cette méthode garantit-elle un profit ?

Non. Une spécification et une validation plus solides réduisent les erreurs d’ingénierie, mais ne suppriment ni le risque de marché ni l’incertitude des performances.

POLARIS / R21

Faire du temps une permission testable

Faites défiler le schéma horizontalement ou ouvrez-le en grand.

Faire du temps une permission testable
Exemple pédagogique de conception — les valeurs et états ne représentent pas une performance réelle.

Horloge exemple : serveur UTC+2. Fenêtre : [14:25, 14:35).

Les positions ouvertes suivent une règle de gestion distincte.

Ouvrir le schéma complet ↗

Preuve pratique

Faire du temps une permission testable

Session autorisée 22:00–02:00 UTC, début inclus et fin exclue. Le broker passe de UTC+2 à UTC+3 avec son DST; la règle reste en UTC et seule l’heure affichée change.

Session de nuit lors d’un changement d’heure serveur
Événement UTC Serveur UTC+2 Serveur UTC+3 Nouvelle entrée
21:59:59 23:59:59 00:59:59 Bloquée
22:00:00 00:00:00 01:00:00 Autorisée
01:59:59 03:59:59 04:59:59 Autorisée
02:00:00 04:00:00 05:00:00 Bloquée; gestion des positions continue

Chaque news conserve provider-ID, heure initiale/révisée, importance, devise, récupération et âge. Un ID doublon est ignoré; une révision remplace le futur et est loguée. Feed stale ou refresh raté bloque les entrées soumises au calendrier, jamais les sorties protectrices. Un tick tardif utilise la permission actuelle.

Mesurer avec deux replays sur mêmes ticks, seul le flux de permission figé change. Supprimer après coup des trades ne reproduit pas les signaux retardés. Les lignes publiques ont 7 labels temps/session et 3 news, qui peuvent se chevaucher; l’ancien total 13 a un périmètre non publié.

Points à vérifier

  • Tester session nocturne, inclusivité des deux bornes et changement d’heure broker.
  • Rejouer news stale, doublon, révision et premier tick tardif.
  • Séparer entrée, gestion de position et sortie d’urgence.

Limites de cet exemple

La politique est UTC; une politique de session broker exige une source d’heure/DST explicite.

Dossier de qualité de la recherche

Responsabilité éditoriale et sources primaires

Révisé par POLARIS Research

Périmètre des preuves

Cet article associe le fonctionnement documenté des plateformes à des schémas d’implémentation récurrents et anonymisés. Les règles exactes et les éléments clients sont exclus.

Sources primaires

Ces sources étayent le fonctionnement des plateformes ou les concepts de recherche. Elles ne valident pas la performance de POLARIS et ne garantissent aucun résultat futur.

Recherches et applications associées

Explorer le niveau pertinent suivant

Passez de la recherche ciblée à l’ingénierie des systèmes et à la construction de portefeuille sans perdre le contexte de cette page.

Pourquoi davantage de filtres de trading n’aide pas toujours →Contrôles de risque indispensables dans chaque Expert Advisor →

Recherche associée