2026. szeptember 30. · kutatás

A backteszted a legjobb órát szerette. Aztán is kereskedhetsz vele, ha átállítjuk az órát?

A backteszted a legjobb órát szerette. Aztán is kereskedhetsz vele, ha átállítjuk az órát?

Találtál egy egyértelmű eredményt: a kriptós stratégiád hozamának nagy része 13:00 és 14:00 UTC között keletkezik. Ellenőrizted a díjakat, újrafuttattad a backtesztet, és papíron is tesztelted a jelzést. Most egy amerikai részvénypiaci változaton dolgozol, és a legerősebb órának a New York-i idő szerinti 09:30–10:30 közötti időszak tűnik.

Mielőtt bármelyik eredményben megbízol, nézd meg, mit tett az óra. Az Egyesült Államokban a nyári időszámítás miatt a New York-i nyitás egy órával eltolódik az UTC-hez képest. Ha a jellemzőid, a kereskedési időszak címkéi és a megbízások eltérő időértelmezést használnak, lehet, hogy a stratégia egy naptári határt aknáz ki egy ismétlődő piaci mintázat helyett.

Nem kell felhagynod a napszakhoz kötődő kutatással. Azt kell meghatároznod, hogy a hipotézised melyik órához kötődik, majd a backteszt minden részét következetesen ehhez igazítanod.

Először pontosítsd, mit jelent az óra

„Az első óra” pontosnak hangzik, amíg meg nem nevezed a viszonyítási időt. Jelentheti a NYSE nyitása utáni első 60 percet, a New York-i helyi idő szerinti 09:30–10:30-as sávot vagy egy rögzített UTC-intervallumot. Az év egy részében ezek a meghatározások egybeesnek, a nyári időszámítás váltásakor viszont eltérnek.

A részvénypiaci hipotézishez a tőzsde helyi kereskedési idejét használd: New Yorkban a 09:30 akkor is 09:30, ha éppen EST vagy EDT van érvényben. A kriptós hipotézisnél lehet, hogy egy rögzített UTC-óra a kívánt változó. A kriptovalutákkal éjjel-nappal kereskednek, így nincs tőzsdei nyitás, amihez a feltevést köthetnéd.

Még a hangolás előtt rögzítsd az időszak meghatározását. „Kereskedj a rendes kereskedési idő kezdetét követő első órában” — ez tesztelhető. „Kereskedj abban az órában, amikor a jelzés a legjobban működik” — ez arra ösztönzi az optimalizálót, hogy a stratégiával együtt az időértelmezést is megválassza.

Hol csúszhatnak be az időeltérések

Tegyük fel, hogy a részvénypiaci adataid UTC-ben vannak tárolva, a jellemzőket előállító kódod UTC-óránként csoportosítja a sorokat, a végrehajtási szabályaid pedig New York-i idő szerint 09:30-kor nyitnak pozíciót. A nyári időszámításra való átállás után a piaci nyitás 14:30 UTC-ről 13:30 UTC-re kerül. Az UTC szerinti idősáv alapján „első órának” címkézett jellemző így már a kereskedési időszak egy másik részére vonatkozik.

Hasonló csapda leselkedik rád, amikor időbélyegekből gyertyákat állítasz elő. Ha UTC-ben végzed az újramintavételezést, majd New York-i időre váltod a címkéket, váratlan határokat kaphatsz. Ez különösen a tavaszi átálláskor fordulhat elő, amikor egy helyi óra nem létezik, illetve az őszi átálláskor, amikor egy helyi óra kétszer fordul elő. Az őszi átállás vasárnapján az 01:30-as helyi időbélyeg nem egyértelmű, hacsak nem tartalmaz UTC-eltolást, vagy nincs UTC-ben megadva.

A naptár a kriptós eredményednél is számíthat. Egy UTC-órára épülő stratégia hónapokig egybeeshet az amerikai piaci aktivitással, majd úgy tűnhet, mintha eltolódna, amikor az Egyesült Államokban átállítják az órát. Ettől még nem érvénytelen a stratégia, de más állítást tehetsz róla. Lehet, hogy egy rögzített UTC-mintázatot mértél, amely időnként átfed az amerikai piac nyitásával, nem pedig a nyitáshoz kötődő hatást.

Építsd be a kereskedési időszak óráját a tesztbe

Az események időbélyegeit tartsd meg UTC-ben, ez legyen az irányadó nyilvántartás. A helyi kereskedési időszak mezőit egy névvel megadott időzóna — például America/New_York — alapján származtasd, történelmi szabályváltozásokat is kezelő időzóna-adatbázissal. Ne rögzítsd keményen az „UTC mínusz öt” vagy „UTC mínusz négy” értéket: egyik eltolás sem adja meg egész évben a New York-i időt.

DöntésRészvénypiaci példaKriptós példa
A hipotézis időalapjaA rendes kereskedési idő kezdetétől eltelt percekA nap UTC szerinti órája
Kereskedési időszak forrásaTőzsdei naptár, ünnepnapokkal és rövidített kereskedési napokkalFolyamatos UTC-naptár
Megbízás időzítéseA jelzést követő első végrehajtható eseményA jelzést követő első végrehajtható esemény

Ezután teszteld külön az átállás körüli heteket. Hasonlítsd össze a teljesítményt minden egyes nyári időszámítási váltás előtt és után, és nézd meg, hogy a nyerő időszak továbbra is a piaci kereskedési időhöz kötődik-e, vagy rögzítve marad UTC-ben. Ha sok órát, dátumot és eltolást vizsgáltál a legjobb eredmény megtalálásához, ezt a keresést is vedd figyelembe a túlillesztési elszámolásban: az időválasztás is egy újabb próbálkozás volt.

Az időzóna szabálykészlet, nem egy levonandó óraszám. Tárold az eseményeket UTC-ben; amikor szükséged van rá, számítsd ki a helyi piaci időt.

Mit kell megerősítenie a papíron futtatásnak

Amikor papíron futtatod a stratégiát, naplózd az esemény UTC-időbélyegét és a kereskedési időszak kezdetétől számított percet is. Így gyorsan észreveheted, ha a stratégia 09:30-ra teszi a nyitást, de valójában helyi idő szerint 10:30-kor lép működésbe. Ellenőrizd az ünnepnapokat és a rövidített kereskedési napokat is; ha minden hétköznapra a szokásos menetrendet alkalmazod, a stratégia gond nélkül kitalálhat olyan kereskedéseket is, amikor a tőzsde zárva van.

Az óraátállításkor állj ellen a kísértésnek, hogy az eredményt a jelzés eltolásával „javítsd”, amíg a tőkeérték-görbe ismerősnek nem tűnik. Először ellenőrizd a megadott hipotézist, a naptárat és a megbízások időzítését. Ha az eredmény a piaci kereskedési idővel együtt mozdul el, tanultál valamit a kereskedési időszak viselkedéséről. Ha ugyanahhoz az UTC-órához kötve marad, akkor valami mást tudtál meg. A backtesztnek meg kell őriznie ezt a különbséget.

napon belüli szezonalitásidőzónákbackteszteléspiaci nyitvatartásadatmérnökség
← Összes bejegyzés