Estou completamente perdido - página 4

 
ydrol:

O fuso horário para a data (segundos depois de 1970) é baseado no UTC. Assim como a hora Unix. É o UnixTime - tempo unix de 64 bits.

data hora - data hora = longo (duração de segundos)

data hora +/- segundos(longo) = data hora(outra data)

data hora +/- segundos(int) = data hora(outra data)


Como especificar uma data em GMT ?
 
ydrol: O fuso horário para a data (segundos depois de 1970) é baseado no UTC.
Falso. O fuso horário é o tempo do servidor do corretor. Depende do corretor que você estiver usando.
FMIC: VOCÊ É O TROLLL aqui! Este é meu último post sobre este tópico! Você não vale a pena o esforço.

Por favor, não alimente o TROLL.

Quando você responde, você dá poder ao troll. Quando você ignora o troll, ele passa fome por atenção e eventualmente morre.

 
FMIC: VOCÊ É O TROLL aqui! Este é o meu último post neste tópico! Você não vale a pena o esforço.

Acho que você fez uma excelente contribuição. Seus cargos são concisos e bem ensinados e você recebe muitas resoluções de "obrigado" por seus esforços.

Sim, eu acho que você fez tudo o que podia por este homem.

 
ah sim, na maioria das vezes, em mql o fuso horário depende de onde você obteve o tempo de. que geralmente é o corretor. esqueceu-se disso, obrigado pelas grandes False heads up -lol
 
RaptorUK:
Como especificar uma data em GMT ?

whoop esqueceu o mql4 usa um conceito de tempo quebrado, . Eu concebi a retórica q :-) o fuso horário depende de onde ele veio. daí todos os problemas, pois existem múltiplas fontes corretor, computador, backtesting blah blah
 
ydrol:
whoop esqueceu o mql4 usa um conceito de tempo quebrado, . Eu concebi a retórica q :-) o fuso horário depende de onde ele veio. daí todos os problemas, pois existem múltiplas fontes corretor, computador, backtesting blah blah
Fico feliz que você tenha recebido a retórica q
 

Eu temia que as regras de promoção do tipo de dados funcionassem dessa forma. Ok, então:

data/hora - data/hora = longo (duração de segundos)

data hora +/- segundos(longo) = data hora(outra data)

data hora +/- segundos(int) = data hora(outra data)

Mas se eu disser X=Y-Z, ou (Y-Z)/60, ou algo assim, onde X já é declarado como um longo ou um int, e Y e Z são datas, isso é muito, muito ruim? E se assim for, será que a transmissão_estática consertaria tudo?

Raptoruk, não é independente do fuso horário. É claro que a diferença entre as 14h e as 15h é de 3600 em qualquer fuso horário. Mas e se eu souber que o comércio pára às 17h, horário do leste, na sexta-feira, mas não sei em que horário do fuso horário 0 (meia-noite de 1º de janeiro de 1970) está? Então temos um problema, não temos! Então o dia 1º de janeiro de 1970 era uma quinta-feira. Se o horário 0 estiver no GMT, então a negociação pára às 46 horas depois disso, ou 165600 modulo 604800. Em outras palavras, com 604800 segundos em uma semana, eu uso a operação aritmética X%604800 para o restante na divisão por 604800, e a negociação pára em 165600. Entretanto, se o corretor estiver a 2 fusos horários a leste disso e seu lixo estiver marcado com algo que seja 7200 mais alto, então a negociação pára quando o tempo%604800 é 172800, e não 165600.

Parece que há incerteza sobre os índices de tempo relatados. Acho que tenho que ter meu código para descobrir os horários em que o modulo 604800 começa e pára, afinal de contas, só para ter certeza. Estou pensando em olhar através de algo como o iTime ('USDJPY',60,X) e encontrar lacunas de 48 horas. Posso confiar que o iTime seja o horário "aberto", o INÍCIO da hora, certo? Em outras palavras, a negociação pára 1 hora após o último índice de tempo antes de um intervalo de 2 dias, e é retomada exatamente no início do primeiro após o intervalo, e depois a adição de múltiplos de 604800 simplesmente muda a semana. Embora houvesse complicações adicionais, como o que aconteceria se em alguma semana, fosse perdendo a última hora, ou faltando a primeira hora. Talvez usar o iTime ('USDJPY',1,X) para que eu esteja fora por minutos, no máximo.

Oh uau, muitos postes são disparados tão rapidamente por aquele. Só para que todos saibam, acho que o raptoruk está bem afinal, mas um monte de invectivos não é bem-vindo, então se você não é ydrol ou raptoruk ou alguém novo com algo novo para dizer, basta parar de postar, eu não sou um troll porque não me importo com seus estados emocionais de uma forma ou de outra e se você tem mais alguma coisa para lançar, saiba que isso cai em ouvidos surdos.

 
zortharg:

Eu temia que as regras de promoção do tipo de dados funcionassem dessa forma. Ok, então:

data/hora - data/hora = longo (duração de segundos)

data hora +/- segundos(longo) = data hora(outra data)

data hora +/- segundos(int) = data hora(outra data)

Mas se eu disser X=Y-Z, ou (Y-Z)/60, ou algo assim, onde X já é declarado como um longo ou um int, e Y e Z são datas, isso é muito, muito ruim? E se assim for, será que a transmissão_estática consertaria tudo?

Raptoruk, não é independente do fuso horário.

OK, que fuso horário é uma data/hora de 0 ?

Mas e se eu souber que o comércio pára às 17h, horário do leste, na sexta-feira, mas não sei em que horário do fuso horário 0 (meia-noite de 1º de janeiro de 1970) está? Então temos um problema, não temos!

Não... bem, talvez você tenha, eu não tenho, não, não temos. Eu conheço o fuso horário dos meus corretores para que eu possa ajustar o horário das 17h de sexta-feira de acordo e obter a data ajustada para as 17h de sexta-feira.
 
zortharg:

Eu temia que as regras de promoção do tipo de dados funcionassem dessa forma. Ok, então:

data/hora - data/hora = longo (duração de segundos)

data hora +/- segundos(longo) = data hora(outra data)

data hora +/- segundos(int) = data hora(outra data)

Mas se eu disser X=Y-Z, ou (Y-Z)/60, ou algo assim, onde X já é declarado como um longo ou um int, e Y e Z são datas, isso é muito, muito ruim? E se assim for, será que a transmissão_estática consertaria tudo?


Estas não são "regras de promoção" apenas eu sendo sensato (espero!). Em geral, eu mesmo faria as previsões acima.

Se o resultado do meu cálculo ainda for um número que seja segundos desde 1/1/1970 (independentemente do fuso horário ou falta dele), então eu o manteria como uma data/hora.

Caso contrário, qualquer outra coisa (uma duração, minutos desde 1/1/1970 o que quer que seja) eu provavelmente guardaria como um longo período. (às vezes uma int, esp por durações típicas, etc.)


Dito isto, estou intrigado como os projetistas da MQL4 chegaram a não exigir o UTC para todos os dados de data, e forçar todos os corretores a enviarem dados UTC, e apenas fazer com que o cliente os interprete em tempo local, porque sua abordagem atual complica desnecessariamente tudo o que está acontecendo a jusante.

Isso torna o cálculo do horário GMT, e o horário de abertura/fechamento da sessão durante o backtesting mais difícil do que deveria ser, se você quiser fazê-lo corretamente para todas as fontes de dados de tick.

(Por exemplo, Alpari tem múltiplos fusos horários em seus dados históricos, portanto você tem que ter cuidado com suas fontes de dados ao fazer o backtesting)

PS Edited my earlier falsie :)

 

ydrol, pelo amor de tudo o que é sagrado ou o que quer que seja, por favor, me diga - se você sabe - se a transmissão_estática pode ser usada em mql4! É o mesmo que em C++? Esta página https://docs.mql4.com/basis/types/casting nunca menciona isto, não consigo encontrá-lo nos fóruns, não consigo encontrá-lo em lugar algum. Estou me deparando com situações em minha codificação constantemente, não apenas na hora de tornar a data longa, mas na hora de dobrar, onde é inevitável, então eu quero fazer isso corretamente. O programa calcula em que parte da semana está uma amostra e a enfatiza em seus cálculos - mas o módulo de tempo o número de segundos em uma semana ainda é uma variável do tipo data/hora e, a menos que eu possa lançá-la como outra coisa, ela está presa dessa forma. Mas preciso realizar uma função matemática dela, e que seja um duplo no final, você vê. Se você não sabe, então não se preocupe, mas por favor me diga se você faz como eu devo datilografar corretamente as coisas neste tipo de situação.

raptoruk, "Não... bem, talvez você faça, eu não, não, nós não fazemos". Não para mim, não para você, não para nós, mas para a validade de sua afirmação anterior de que é independente do fuso horário. Porque não importa em que fuso horário seu corretor está, negociar no mercado forex não segue o relógio do seu corretor. São 17 horas do leste na sexta-feira e no domingo. 22:00 h GMT. E quanto ao horário de verão/hora padrão! E quanto a isso! Alguns países não adicionam uma hora ou subtraem, ou fazem isso em um dia diferente, então você pode acabar com um código que é uma hora de folga para partes do ano, se não houver uma maneira agradável de fazer isso. Eu, eu ainda não me instalei em um corretor. O que estou tentando é no GMT+2, mas acho que agora não gosto deles, com base em sua conta demo. E se eu tentar uma de verdade, talvez eu queira usar uma diferente em seu lugar. Portanto, não quero que o fuso horário do corretor seja codificado no programa se for uma questão fácil não fazer isso. Não seja como aquele outro cara novamente, tentando distorcer tudo em uma oportunidade de lançar um insulto em vez de levar a pergunta ao valor de face.

Razão: