Encontraste um resultado claro: a tua estratégia de cripto obtém a maior parte da rentabilidade entre as 13:00 e as 14:00 UTC. Verificaste as comissões, voltaste a executar o backtest e testaste o sinal em paper trading. Agora estás a preparar uma versão para ações dos EUA, e a hora mais forte parece ser das 09:30 às 10:30, hora de Nova Iorque.
Antes de confiares em qualquer um dos resultados, verifica o que aconteceu ao relógio. A mudança para a hora de verão nos EUA adianta a abertura de Nova Iorque em 1 hora face à UTC. Se as tuas features, etiquetas de sessão e ordens usarem referências temporais diferentes, a estratégia pode estar a explorar uma fronteira do calendário em vez de um padrão de mercado repetível.
Não precisas de abandonar a investigação sobre a hora do dia. Tens de definir a que relógio se refere a tua hipótese e, depois, garantir que todas as partes do backtest o usam de forma consistente.
Primeiro, define o que significa a hora
«A primeira hora» parece preciso até definires o relógio de referência. Pode significar os primeiros 60 minutos após a abertura da NYSE, o período das 09:30 às 10:30 na hora civil de Nova Iorque ou um intervalo fixo em UTC. Estas definições coincidem durante parte do ano e divergem quando muda a hora.
Para a hipótese sobre ações, usa a hora local da sessão da bolsa: 09:30, hora de Nova Iorque, significa 09:30 quer Nova Iorque esteja em EST ou EDT. Para a hipótese sobre cripto, a variável pretendida pode ser uma hora fixa em UTC. Como o mercado cripto funciona 24 horas por dia, não há um toque de abertura de uma plataforma que sirva de referência para a afirmação.
Regista a definição antes de afinares a estratégia. «Negociar durante a primeira hora após a abertura da sessão regular» é testável. «Negociar na hora em que o sinal funciona melhor» dá ao otimizador margem para escolher uma convenção horária, além da estratégia.
Onde surgem as incompatibilidades horárias
Imagina que os dados de ações estão armazenados em UTC, o teu código de features agrupa as linhas por hora UTC e as regras de execução abrem posições às 09:30, hora de Nova Iorque. Depois da mudança para a hora de verão, a abertura do mercado passa das 14:30 UTC para as 13:30 UTC. Uma feature identificada como «primeira hora» pelo seu intervalo UTC passa a referir-se a outra parte da sessão.
Surge uma armadilha semelhante quando constróis barras a partir de timestamps. Se fizeres a reamostragem em UTC e depois converteres as etiquetas para a hora de Nova Iorque, podes obter limites inesperados, sobretudo na transição da primavera, quando uma hora local não existe, e na transição do outono, quando uma hora local ocorre 2 vezes. Um timestamp como 01:30, hora local, é ambíguo nesse domingo de outono, a menos que inclua um desvio UTC ou esteja representado em UTC.
O calendário também pode ser relevante para o teu resultado em cripto. Uma estratégia baseada na hora UTC pode coincidir com a atividade do mercado dos EUA durante meses e, depois, parecer mudar quando os relógios nos EUA mudam. Isso não invalida a estratégia; altera aquilo que podes afirmar. Podes ter medido um padrão fixo em UTC que, por vezes, coincide com a abertura dos EUA, em vez de um efeito associado a essa abertura.
Integra o relógio da sessão no teste
Mantém os timestamps dos eventos em UTC como registo canónico. Deriva os campos da sessão local a partir de um fuso horário identificado, como America/New_York, recorrendo a uma base de dados de fusos horários que contemple alterações históricas às regras. Não fixes «UTC menos 5» ou «UTC menos 4»: nenhum desses desvios define a hora de Nova Iorque durante todo o ano.
| Decisão | Exemplo de ações | Exemplo de cripto |
|---|---|---|
| Relógio da hipótese | Minutos desde a abertura da sessão regular | Hora UTC do dia |
| Fonte da sessão | Calendário da bolsa, incluindo feriados e encerramentos antecipados | Calendário UTC contínuo |
| Momento da ordem | Próximo evento executável após o sinal | Próximo evento executável após o sinal |
Depois, testa separadamente as semanas em torno da mudança da hora. Compara o desempenho antes e depois de cada mudança e verifica se o intervalo vencedor continua associado à sessão do mercado ou se permanece fixo em UTC. Se pesquisaste muitas horas, datas e desvios para encontrar o melhor resultado, inclui essa pesquisa no cálculo do sobreajuste: a escolha do relógio foi mais uma tentativa.
Um fuso horário é um conjunto de regras, não um número de horas a subtrair. Armazena os eventos em UTC; deriva a hora local do mercado quando precisares dela.
O que o teu teste em paper trading deve confirmar
Ao passar a estratégia para paper trading, regista tanto o timestamp UTC do evento como o minuto relativo à sessão. Assim, consegues detetar rapidamente uma estratégia que julga que a abertura é às 09:30, mas que, na realidade, dispara às 10:30, hora local. Confirma também os feriados e os encerramentos antecipados; um horário de sessão normal aplicado a todos os dias da semana vai criar transações em dias em que a bolsa está fechada.
E quando os relógios mudarem, resiste à tentação de «corrigir» um resultado deslocando o sinal até a curva de capital parecer familiar. Primeiro, confirma a hipótese declarada, o calendário e o momento das ordens. Se o resultado acompanhar a sessão do mercado, aprendeste algo sobre o comportamento da sessão. Se permanecer na mesma hora UTC, aprendeste outra coisa. O teu backtest deve preservar essa distinção.
← Todos os artigos
