Trabalhando com o tempo (Parte 1): princípios básicos
1 342
0
Em que momento
O uso adequado do tempo é um aspecto muito importante do trading. Este nos permite saber, por exemplo, se a Bolsa de Londres ou Nova Iorque já abriu ou ainda não ou a que horas começa/termina o pregão no mercado de moedas. Para os traders que negociam manualmente, o problema do timing é menos delicado. Existem muitas maneiras de determinar o momento certo para negociar: informações na Internet, as características do instrumento financeiro, o horário individual de cada um, etc. Se o trader negocia apenas com base na dinâmica de preços, compra e vende quando ocorre um sinal gerado pelas mudanças do preço, o tempo em si provavelmente não importa muito. Porém, existe outros tipos de operadores: scalpers noturnos que negociam após o fechamento do pregão na Bolsa de Valores de Nova York e antes da abertura da sessão nos mercados europeus, ou aqueles que aguardam o momento de maior atividade na sessão de Londres, sem mencionar aqueles que operam ações e futuros. Estes não se enquadram no horário da corretora, já que precisam é do horário local real - p.e, dos Estados Unidos, do Japão, de Londres, da Europa ou de Moscou - para entender exatamente quando um mercado em particular abre e fecha, além disso, ao negociar futuros, para eles é importante entender quando um determinado futuro está sendo negociado.
Horário de verão/inverno e mudança de horário da corretora
Operar manuseando o tempo é mais fácil quando você compra e vende diretamente na tela de seu computador. Podemos conhecer o tempo através da Internet usando ferramentas especiais, relógios de mesa, funções do sistema cujos valores podem ser obtidos usando funções MQL, tais como TimeGMT(), TimeGMTOffset(), etc. No entanto, o cenário é outro quando precisamos escrever e testar com base em dados históricos um programa que opera com o tempo. E, como na negociação real, não é difícil encontrar a solução disso.
Peguemos o UTC (Tempo Universal Coordenado) ou GMT (Tempo Médio de Greenwich, https://greenwichmeantime.com/what-is-gmt/) e acrescentemos a mudança de tempo necessária com base na localização geográfica ou no horário de negociação do instrumento para obter a hora correta. Mas não é assim tão simples, uma vez que há também uma transição para o horário de inverno/verão que faz o relógio avançar ou retroceder uma hora. De qualquer forma, trata-se de um parâmetro não uniforme, pois a transição dependerá das tradições regionais. Assim, alguns países, ou mesmo regiões inteiras, têm usado um horário de transição constante por muitos anos (UE e EUA), enquanto outros têm mudado este parâmetro - a Rússia cancelou o horário de verão em 2014. A Europa manteve discussões a esse respeito em 2018. Nessa altura, foi realizada uma sondagem sobre a eliminação da mudança de horário (https://ec.europa.eu/germany/news/20180831-konsultation-sommerzeit_de), que mostrou que a maioria dos entrevistados era a favor da eliminação. Após a sondagem, a Comissão Européia apresentou uma proposta legislativa para suprimir a mudança da hora de inverno/verão (https://ec.europa.eu/germany/news/20180914-kommission-gesetzesvorschlag-ende-zeitumstellung_de), o que, no entanto, não levou a nada.
E além de toda essa confusão de horários, as próprias corretoras complicam as coisas pela forma como estabelecem a hora de seu servidor. Em 2015, uma corretora alemã mandou a seguinte mensagem para mim:
- Até 8 de março de 2015, nosso servidor MT4 estava configurado com o horário de Londres (= GMT).
- De 8 a 29 de março de 2015 a hora será definida de acordo com CET (GMT + 1).
- Em 19 de março, o servidor será configurado com a hora de Londres (GMT + 1)
Ou seja, a corretora alemã usa GMT + hora de inverno (DST) nos EUA ou (principalmente) hora de Londres + DST nos EUA. Em princípio, isso faz sentido, porque a sessão de negociação no mercado Forex começa às 17h00, horário de Nova Iorque - aqui novamente, tudo depende das peculiaridades da transição do horário americano. Como resultado, para os residentes de Frankfurt, o pregão às vezes pode começar às 21h, mais frequentemente às 22h, e por uma ou duas semanas por ano, às 23h.
Para nós, traders e clientes, isto acaba por ser uma espécie de jardim de infância. Todo o mundo faz como entender. Traders e desenvolvedores têm que lidar com diferentes valores de tempo, e cada um desses valores pode ser importante. Por isso, os parâmetros de tempo devem ser definidos utilizando os recursos e possibilidades da linguagem MQL disponíveis. O que infelizmente não funciona quando o indicador, script ou EA está rodando no testador de estratégia.
Neste artigo, tentaremos mudar isso. Em vez de enviar consultas à corretora, determinaremos o valor de mudança de horário necessário, para que, a qualquer momento, possamos determinar o GMT para qualquer marca de tempo no testador de estratégia e, consequentemente, qualquer horário local, como o de Nova Iorque. Além disso, já que abordamos este tópico, vamos fazer com que seja possível determinar o tempo restante até o fechamento do mercado. Essa informação é muito importante para quem costuma fechar as posições abertas antes do fim de semana. Porém, estas funções serão tratadas especificamente no segundo artigo, pois para começar precisamos desenvolver substituições de macro para simplificar os cálculos e representações nas funções mencionadas.
Substituições de macro
Todo o código considerado aqui está disponível no arquivo de inclusão anexado DealingWithTimePart1.mqh. Várias substituições de macro são apresentadas no início do arquivo.
Em primeiro lugar, as mudanças de horário de diferentes regiões são incluídas para que você não tenha que buscar os valores necessários a cada vez:
//--- defines #define TokyoShift -32400 // always 9h #define NYShift 18000 // winter 17h=22h GMT: NYTime + NYshift = GMT #define LondonShift 0 // winter London offset #define SidneyShift -39600 // winter Sidney offset #define FfmShift -3600 // winter Frankfurt offset #define MoskwaShift -10800 // winter Moscow offset #define FxOPEN 61200 // = NY 17:00 = 17*3600 #define FxCLOSE 61200 // = NY 17:00 = 17*3600 #define WeekInSec 604800 // 60sec*60min*24h*7d = 604800 => 1 Week
Para uma melhor compreensão, vamos concordar que o GMT é uma referência de tempo imutável, enquanto diferentes horários locais, como Nova Iorque, Londres ou Moscou, diferem dele por alguma variação de tempo. Da mesma forma, através da variável, trabalharemos também com a transição para o verão ou inverno. A razão é simples. Os sinais de uma diferença de tempo variável são definidos da seguinte forma
tempo variável + mudança de horário variável = GMT
Por exemplo:
Moscou (16 h) + mudança para Moscou (-3 h) = GMT (13 h)
Nova York (16 h) + mudança para Nova York (+5 h) = GMT (21 h)
Nova York (16 h) + (mudança para Nova York (+5 h) + DST_US(-1 h)) = GMT (20 h)
Frankfurt (16 h) + (mudança para Frankfurt (-1 h) + DST_US(-1 h)) = GMT (14 h)
Preste atenção aos parênteses! Parênteses são importantes ao calcular as variáveis de tempo a partir da hora GMT:
Nova York (16 h) = GMT (20 h) - (mudança para Nova York (+5 h) + DST_US(-1 h)) => 20 -(+5 + -1) = 20 - 5 +1 = 16 h
Frankfurt (16 h) = GMT (14 h) - (mudança para Frankfurt (-1 h) + DST_US(-1 h)) => 14 -( -1 + -1) = 14 +1 +1 = 16 h
O uso indevido de parênteses é comumente causado por erros de digitação.
Da mesma forma, a MQL5 e o sistema do computador processam as diferencias de tempo, por exemplo: TimeGMTOffset(): TimeLocal() + TimeGMTOffset() = TimeGMT()) ou TimeDaylightSavings(): TimeLocal() + TimeDaylightSavings() = horário de inverno ou horário local padrão do computador.
E no final desta parte mencionaremos FxOpen e FxClose, e também a duração de uma semana inteira em segundos WeekInSec - tais designações são muito mais fáceis de entender, do que se, por exemplo, encontrarmos inesperadamente o valor 604800 no código.
Vamos acrescentar mais duas modificações à saída da variável. TOSTR(A) exibe o nome e o valor da variável. Também existe uma matriz com nomes abreviados dos dias da semana. Essas designações aparecem várias vezes no código deste projeto. Elas permitem economizar espaço na string e também permitem que as macas de tempo calculadas sejam corretamente identificadas:
#define TOSTR(A) #A+":"+(string)(A)+" " // Print (TOSTR(hGMT)); => hGMT:22 (s.b.) string _WkDy[] = // week days { "Su.", "Mo.", "Tu.", "We.", "Th.", "Fr.", "Sa.", "Su." };
A seguir estão as opções de cálculo de tempo que permitem evitar a solução alternativa associada ao uso da estrutura MQL MqlDateTime e à leitura de um valor escalar. Os valores são calculados diretamente:
#define DoWi(t) ((int)(((t-259200)%604800)/86400)) // (int)Day of Week Su=0, Mo=1,... #define DoWs(t) (_WkDy[DoWi(t)]) // Day of Week as: Su., Mo., Tu., ....
A função DoWi(t) (Day of Week as integer) definirá o dia da semana como um número inteiro (domingo = 0, segunda-feira = 1, etc.), já DoWs(t) Day of Week as string) devolverá o nome abreviado do dia da semana como texto com base no valor DoWi(t) e na matriz _WkDy[]. Como na segunda parte do artigo estaremos trabalhando com a última e primeira hora do fim de semana, usaremos com frequência as seguintes substituições de macro.
#define SoD(t) ((int)((t)%86400)) // Seconds of Day #define SoW(t) ((int)((t-259200)%604800)) // Seconds of Week
A função SoD(t) (Seconds of the day) retorna o número de segundos decorridos desde 00:00. Assim, SoD(TimeCurrent()) calcula o tempo decorrido desde o início da formação da vela diária, em segundos. Da mesma forma, SoW(t) calcula o número de segundos decorridos desde as 00:00 do último domingo. Permite calcular a porcentagem de tempo decorrido e tempo restante. Se dividirmos o valor por 864 (=0.01*24*60*60), o resultado será o tempo do dia decorrido como uma porcentagem:
(double)SoD(D’20210817 15:34‘) / 864. = 64.86% 86400 - SoD(D’20210817 15:34‘) = Print("D'20210817 15:34': ", DoubleToString((double)SoD(D'20210817 15:34')/864.0, 2),"% ", 86400 - SoD(D’20210817 15:34‘),“ sec left“ );
Se necessário, os seguintes cálculos podem ser usados:
#define MoH(t) (int(((t)%3600)/60)) // Minute of Hour #define MoD(t) ((int)(((t)%86400)/60)) // Minute of Day 00:00=(int)0 .. 23:59=1439
A função ToD(t) retorna o número de segundos do dia como um valor do tipo datetime. Esta representação evita avisos do compilador:
#define ToD(t) ((t)%86400) // Time of Day in Sec (datetime) 86400=24*60*60
A função HoW(t) retorna o número de horas que se passaram desde domingo 00:00:
#define HoW(t) (DoW(t)*24+HoD(t)) // Hour of Week 0..7*24 = 0..168 0..5*24 = 0..120
A seguir, veremos como calcular a hora do dia. O resultado será um número inteiro, não uma data:
#define HoD(t) ((int)(((t)%86400)/3600)) //Hour of Day: 2018.02.03 17:55 => 17
Agora com arredondamento:
#define rndHoD(t) ((int)((((t)%86400)+1800)/3600))%24 // rounded Hour of Day 17:55 => 18
Agora em formato datetime:
#define rndHoT(t) ((t+1800)-((t+1800)%3600)) // rounded Hour of Time: 2018.02.03 17:55:56 => (datetime) 2018.02.03 18:00:00
Hora de início do dia em formato datetime, que de outra forma teria que ser determinado adicionalmente chamando o período gráfico D1:
#define BoD(t) ((t)-((t)%86400)) // Begin of day 17.5 12:54 => 17.5. 00:00:00
Hora de início da semana em formato datatime, que de outra forma teria que ser determinado chamando o período gráfico semanal:
#define BoW(t) ((t)-((t-172800)%604800 - 86400)) // Begin of Week, Su, 00:00
Os fragmentos a seguir usam estruturas e funções MQL porque a conversão parecia muito complicada para mim, por exemplo, por causa dos anos bissextos. No entanto, usamos o mesmo formato, isto é, funções de tempo com nomes de três letras ou abreviaturas: DoY - dia do ano, MoY - mês do ano e YoY - ano do ano:
MqlDateTime tΤ; // hidden auxiliary variable: the Τ is a Greek characker, so virtually no danger int DoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.day_of_year); } int MoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.mon); } int YoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.year); }
Este é outro cálculo da semana do ano de acordo com a definição americana:
int WoY(datetime t) //Su=newWeek Week of Year = nWeek(t)-nWeeks(1.1.) CalOneWeek:604800, Su.22:00-Su.22:00 = 7*24*60*60 = 604800 { return(int((t-259200) / 604800) - int((t-172800 - DoY(t)*86400) / 604800) + 1); // calculation acc. to USA }
(Para saber mais sobre o calendário, consulte https://en.wikipedia.org/wiki/Week#Numbering)
Diferenças horárias sazonais e locais
Fizemos o trabalho preparatório necessário para utilizar as funções. Agora precisamos preparar uma grande variedade de mudanças locais e sazonais. Vamos ver como as corretoras lidam com elas. Vamos começar com a linguagem de programação MQL5.
Tempo em MQL5
A primeira e mais importante coisa que encontramos é o horário das cotações da corretora. Trata-se do tempo de abertura da barra que pode ser obtido para a última cotação recebida usando a função TimeCurrent(). Em muitos casos (e isto pode parecer surpreendente), esse tempo é relativamente sem importância. Serve apenas para classificação de barras, preços, bem como operações de negociação no tempo. Ou seja, este tempo só é importante no ambiente do terminal durante negociação real.
Existe também a função TimeTradeServer(): "Retorna a hora atual estimada do servidor de negociação. Ao contrário da função TimeCurrent(), o valor da hora é calculado no terminal do cliente e depende das configurações de hora no computador do usuário". Mas, "Ao trabalhar no testador de estratégias o tempo TimeTradeServer() é modelado de acordo com dados históricos e é sempre igual a TimeCurrent()". Ou seja, essa função é de pouca utilidade se precisarmos otimizar o programa no testador de estratégia.
Ou seja, está associado a TimeGMT() e a TimeLocal(): "Ao testar o valor TimeGMT() é sempre igual ao tempo do servidor simulado TimeTradeServer()", o que, por sua vez é igual a TimeCurrent().
Pela mesma razão, no testador de estratégias a função TimeGMTOffset() é inútil, porque TimeGMTOffset() = TimeGMT() - TimeLocal(), o que é sempre zero no final das contas. :(
E a última coisa que falta é TimeDaylightSavings(): "Retorna a correção do horário de verão em segundos, caso este tenha sido alterado. Depende das configurações de hora no computador do usuário. ... Se o tempo de inverno (padrão) for alterado, 0 será devolvido".
Aqui está o registro da conta de demonstração (a data dá para ver que é horário de verão na UE e nos EUA):
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeCurrent: 10:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeTradeServer: 10:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeLocal: 09:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeGMT: 07:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeDaylightSavings: -3600 h: -1
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeGMTOffset: -7200 h: -2
e aqui uma amostra da mesma conta no testador de estratégia (depuração):
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeCurrent: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeTradeServer: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeLocal: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeGMT: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeDaylightSavings: 0 h: 0
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeGMTOffset: 0 h: 0
Ou seja, todas essas funções funcionam apenas em tempo real, mas não no testador de estratégias. Na verdade, temos apenas a função TimeCurrent(), que nos permite calcular independentemente o resto do tempo necessário.
Em teoria, poderíamos enviar uma consulta à corretora e tentar descobrir como ela determina o tempo para as cotações. Por exemplo, aqui está o que a Alpari respondeu:
(GMT+2/GMT +3 DST) e fecha na sexta-feira às 23:55:00 hora do servidor. No verão
o horário de negociação começa às 21h05 GMT no domingo, já no inverno
às 22:05 GMT no domingo.
Mas isso é apenas parcialmente verdade. Isso não menciona que o horário de verão e o horário de inverno são diferentes na UE e nos EUA, razão pela qual a sessão neste horário de transição, por exemplo, 26.03.2021, não termina às 23:55, mas às 22:55. E antes e depois dessa hora novamente às 23:55.
Antes de continuar, aqui está uma visão geral rápida dos diferentes fusos horários e suas abreviaturas. Para mim, o site mais útil para trabalhar com fusos horários é: https://24timezones.com/time-zones. A tabela do site contém 200 fusos horários diferentes. Aqui estão os mais importantes para nós:
| Abreviatura | Fuso horário | Site | UTC Diff. | GMT Diff. |
|---|---|---|---|---|
| CEST | Horário de verão da Europa Central | Horário de verão de Frankfurt | UTC+2 | GMT+2 |
| CET | Horário da Europa Central | Horário normal de Frankfurt | UTC+1 | GMT+1 |
| EDT | Horário do Leste Europeu | Hora normal de Nova York | UTC-4 | GMT-4 |
| EEST | Horário de verão da Europa Oriental | Horário de verão do Chipre | UTC+3 | GMT+3 |
| EET | Horário da Europa Oriental | Hora normal do Chipre | UTC+2 | GMT+2 |
| EST | Hora Padrão do Leste | Hora normal de Nova York | UTC-5 | GMT-5 |
| ET | Horário do Leste Europeu | Nova York | UTC-5/UTC-4 | GMT-5/GMT-4 |
| GMT | Tempo Médio de Greenwich | Hora normal de Londres | UTC+0 | GMT+0 |
| UTC | Tempo Universal Coordenado | Hora normal de Londres | UTC | GMT |
Observe que a diferença horária normal com Nova York é de -5 horas e no verão de -4 horas, o que é uma hora a menos, enquanto que com Frankfurt +1 ou com o servidor MQ +2, já no verão +2 e +3 respectivamente. Não fique confuso, não se esqueça dos exemplos!
Agora, vejamos as marcas de data e hora da primeira e da última cotação na conta demo da MQ no fim de semana. No gráfico EURUSD M1, ativamos o separador de ponto e pressionamos Enter no gráfico para inserir a data de segunda-feira no formato dd.mm.aaaa (não no formato de data MQ). Rolamos o gráfico um pouco para a direita. Agora, a barra com a linha vertical é a primeira barra da nova semana, enquanto a barra à esquerda é a última barra da semana anterior. Estas são as datas da última barra na sexta-feira e da primeira barra depois do fim de semana:
Fins de semana durante a mudança de horário no outono de 2020:
| Summer-EU | Summer-EU | Summer-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU |
|---|---|---|---|---|---|---|---|---|---|
| Summer-US | Summer-US | Summer-US | Summer-US | Summer-US | Winter-US | Winter-US | Winter-US | Winter-US | Summer-US |
| Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. |
| 2020.10.16 | 2020.10.19 | 2020.10.23 | 2020.10.26 | 2020.10.30 | 2020.11.02 | 2021.03.05 | 2021.03.08 | 2021.03.12 | 2021.03.15 |
| 23:54 | 00:05 | 23:54 | 00:05 | 22:54 | 00:02 | 23:54 | 00:03 | 23:54 | 00:00 |
| 1,1716 | 1,17195 | 1,18612 | 1,18551 | 1,16463 | 1,16468 | 1,19119 | 1,19166 | 1,19516 | 1,19473 |
| 1,17168 | 1,17208 | 1,18615 | 1,18554 | 1,16477 | 1,16472 | 1,19124 | 1,19171 | 1,19521 | 1,19493 |
| 1,1716 | 1,1718 | 1,18596 | 1,18529 | 1,16462 | 1,16468 | 1,19115 | 1,19166 | 1,19514 | 1,19473 |
| 1,1716 | 1,17188 | 1,18598 | 1,18534 | 1,16462 | 1,16472 | 1,1912 | 1,19171 | 1,19519 | 1,19491 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 29 | 22 | 35 | 48 | 30 | 3 | 33 | 2 | 23 | 25 |
| 4 | 11 | 2 | 6 | 2 | 61 | 1 | 38 | 1 | 29 |
Fins de semana durante a mudança de horário na primavera de 2021:
| Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Summer-EU | Summer-EU | Summer-EU |
|---|---|---|---|---|---|---|---|---|---|
| Winter-US | Winter-US | Winter-US | Summer-US | Summer-US | Summer-US | Summer-US | Summer-US | Summer-US | Summer-US |
| Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. |
| 2021.03.05 | 2021.03.08 | 2021.03.12 | 2021.03.15 | 2021.03.19 | 2021.03.22 | 2021.03.26 | 2021.03.29 | 2021.04.02 | 2021.04.05 |
| 23:54 | 00:03 | 23:54 | 00:00 | 22:54 | 00:00 | 22:54 | 00:07 | 23:54 | 00:03 |
| 1,19119 | 1,19166 | 1,19516 | 1,19473 | 1,19039 | 1,18828 | 1,17924 | 1,17886 | 1,17607 | 1,17543 |
| 1,19124 | 1,19171 | 1,19521 | 1,19493 | 1,19055 | 1,18835 | 1,17936 | 1,17886 | 1,17608 | 1,17543 |
| 1,19115 | 1,19166 | 1,19514 | 1,19473 | 1,19038 | 1,18794 | 1,17922 | 1,17884 | 1,17607 | 1,17511 |
| 1,1912 | 1,19171 | 1,19519 | 1,19491 | 1,19044 | 1,18795 | 1,17933 | 1,17886 | 1,17608 | 1,17511 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 33 | 2 | 23 | 25 | 41 | 43 | 17 | 3 | 2 | 3 |
| 1 | 38 | 1 | 29 | 1 | 20 | 5 | 68 | 28 | 79 |
Interessante e não totalmente claro para mim é o fato de que às vezes as últimas cotações antes do fim de semana chegam por volta das 23:00 (22:54), e não às 24:00 (23:54), e as primeiras cotações são sempre recebidas às 00:00 Às vezes, numa perspectiva horária, isso cria um "buraco de 1 hora nas cotações" (fechamento às 23:00, abertura às 00:00), enquanto o mercado Forex sempre fecha às 17:00 (horário de Nova York) na sexta-feira e sempre abre às 17h (horário de Nova York) no domingo. Demos uma olhada especial nos fins de semana, quando ocorre a mudança de horário, e calculemos a hora correspondente nos fusos horários desejados:
| Data |
| Data da última sexta |
|
|
| Data |
|
|
|
|
| últ. barra M1 | próx. barra M1 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Switch US |
| NY-Time | NY-GMT | GMT | Switch EU |
| CET-GMT | CET | EET-GMT | EET | of MQ | of MQ | |
|
| Summer-US | Fr, 16. Oct 20 | 17:00 | GMT + 4 | 21 |
| Summer-EU | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Summer-US | So, 18. Oct 20 | 17:00 | GMT + 4 | 21 |
| Summer-EU | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:05 |
|
| Summer-US | Fr, 23. Oct 20 | 17:00 | GMT + 4 | 21 | 25.10.20 | Summer-EU | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Summer-US | So, 25. Oct 20 | 17:00 | GMT + 4 | 21 |
| Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 |
| 00:05 |
| 01.11.20 | Summer-US | Fr, 30. Oct 20 | 17:00 | GMT + 4 | 21 |
| Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 | 22:54 |
|
|
| Winter-US | So, 1. Nov 20 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 |
| 00:02 |
|
| Winter-US | Fr, 6. Nov 20 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 | 23:54 |
|
|
| Winter-US | So, 8. Nov 20 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 |
| 00:03 |
| 14.03.21 | Winter-US | Fr, 12. Mrz 21 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 | 23:54 |
|
|
| Summer-US | So, 14. Mrz 21 | 17:00 | GMT + 4 | 21 |
| Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 |
| 00:00 |
|
| Summer-US | Fr, 26. Mrz 21 | 17:00 | GMT + 4 | 21 | 28.03.21 | Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 | 22:54 |
|
|
| Summer-US | So, 28. Mrz 21 | 17:00 | GMT + 4 | 21 |
| Summer-EU | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:07 |
|
| Summer-US | Fr, 2. Apr 21 | 17:00 | GMT + 4 | 21 |
| Summer-EU | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Summer-US | So, 4. Apr 21 | 17:00 | GMT + 4 | 21 |
| Summer-EU | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:03 |
Durante a(s) semana(s) em que o horário de verão local na UE e nos EUA não coincide, o mercado de moedas em Nova York abre no domingo às 23:00 EET e fecha na sexta-feira às 23:00 EET. No entanto, algumas corretoras, incluindo o servidor MQ com contas de demonstração, sempre entregam as primeiras cotações no domingo às 24h (ou 00h00 de segunda-feira). Portanto, pode-se pensar que o horário de cotações corresponde à segunda mudança de hora, e não à primeira. No entanto, neste caso, na sexta-feira, a última cotação antes do fechamento do pregão deveria ter ocorrido um pouco antes das 24h, porque somente neste caso o número necessário de horas é 24*5=120. Mas falta 1 hora. Daí a pergunta, quando ela desaparece: na sexta-feira antes do fim de semana ou no domingo depois delas?
Como os preços de fechamento semanais são mais importantes do que a primeira hora do pregão no domingo, pode-se supor que se na sexta-feira os últimos preços fossem um pouco antes das 23h e os próximos fossem apenas às 24h/00h, falta a primeira hora de trabalho do mercado de moedas, domingo, das 23h às 24h, e não na última sexta-feira, das 23h às 24h. Por isso, se a hora dos primeiros preços fosse no domingo imediatamente após as 23:00, seria muito fácil não só reconhecer a mudança de horário, mas também determinar quando o mercado Forex fechará novamente (5d * 24h = 120 horas após a abertura no domingo). Por exemplo, isso é importante para estratégias cautelosas que fecham todas as posições antes do fim de semana.
Primeiro, veremos quais suposições podemos fazer. Nosso testador de estratégias só tem a função TimeCurrent(). Vamos usá-la para determinar a hora GMT ou UTC, a partir da qual podemos facilmente calcular a hora de outros fusos horários. Dados os possíveis feriados e outras razões que podem afetar os horários de abertura e fechamento do mercado nos EUA, vamos supor que:
- O mercado de moedas fecha na sexta-feira às 17:00, horário de Nova York.
- O mercado abre no domingo às 17h, horário de Nova York.
- Normalmente abre às 5*24=120 horas e fecha às 2*24=48 horas.
- Se faltar alguma hora entre as 17h de sexta-feira e as 17h de domingo, as cotações de domingo estarão ausentes até que a primeira cotação seja recebida e não até que as cotações da última sexta-feira apareçam.
- As cotações recebidas (independentemente da hora indicada nelas) estão sempre atualizadas (e não são, por exemplo, de uma hora atrás).
- A corretora não muda sua política de mudança horária.
Conclusões
Definimos funções ou, mais precisamente, substituições de macro que usaremos a seguir. Também estabelecemos as condições que nos permitirão, no próximo artigo "Trabalhando com o tempo (Parte 2): funções", desenvolver funções que calcularão o GMT a qualquer momento.
O artigo é acompanhado pelo arquivo DealingwithTimePart1.mqh, que contém os fragmentos de código vistos. No próximo artigo, novas funções serão adicionadas ao arquivo.
Se você tiver dúvidas, comentários ou sugestões, por favor, escreva.
Traduzido do Inglês pela MetaQuotes Ltd.
Artigo original: https://www.mql5.com/en/articles/9926
Quase-construtor para criar um Expert Advisor
Gráficos na biblioteca DoEasy (Parte 88): coleção de objetos gráficos, matriz dinâmica bidimensional para armazenar propriedades de objetos que mudam dinamicamente
Receitas MQL5: Calendário Econômico
Gráficos na biblioteca DoEasy (Parte 87): coleção de objetos gráficos, controlamos a modificação de propriedades de objetos em todos os gráficos abertos
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso