모두가 알고 있듯이 datetime 변수에는 1970년 1월 1일 이후의 초가 포함됩니다. 00:00 분명히 이것은 유닉스 시간 형식의 프로토타입입니다. 그러나 원본 소스에 매우 중요한 설명이 있습니다. 00:00은 UTC 시간입니다. 그리고 동시에 모든 시간대의 모든 컴퓨터는 동일한 time_t 수치를 제공합니다. 저것들. time_t는 특정 시점을 고유하게 식별합니다. 그리고 time_t를 시간대에 따라 /에서 일광 절약 시간으로 전환하는 규칙에 따라 다른 방식으로 기호 형식으로 변환할 수 있습니다(일반적으로 최종 사용자의 요청에 따라). 즉, 이진 표현이 기본입니다. 그리고 MQ 에서는 트레이딩 서버 시간 (심볼릭)을 기본으로 하는 것이 더 쉬울 것이라고 결정했습니다. 그리고 이것이 파슬리가 밝혀진 방법입니다. 예를 들어 이제 time_t == 100000이고 UTC+1 거래 서버는 103600에 새 막대에 서명하고 다른 UTC+2 무역 서버는 107200에 새 막대에 서명합니다. 즉. 같은 기간을 표시하는 막대는 datetame 필드에 다른 숫자가 있습니다. 얼핏 보면 헛소리처럼 보입니다. 그러나 미국의 서버에서 유럽의 서버로 상태를 전송하려고 시도하십시오. 고정 시간만큼 어리석게 이동하면 일광 절약 시간제에서 /로의 전환이 다른 날에 발생하기 때문에 데이터가 일년에 두 번 퍼집니다. . 예를 들어 일부 서버는 시간을 SET에서 EET로 변경했습니다. 이제는 병 없이 교대 근무가 어디 있는지 확인하는 것이 불가능합니다.
kazakov.v : 모두가 알고 있듯이 datetime 변수에는 1970년 1월 1일 이후의 초가 포함됩니다. 00:00 분명히 이것은 유닉스 시간 형식의 프로토타입입니다. 그러나 원본 소스에 매우 중요한 설명이 있습니다. 00:00은 UTC 시간입니다. 그리고 동시에 모든 시간대의 모든 컴퓨터는 동일한 time_t 수치를 제공합니다. 저것들. time_t는 특정 시점을 고유하게 식별합니다. 그리고 time_t를 시간대에 따라 /에서 일광 절약 시간으로 전환하는 규칙에 따라 다른 방식으로 기호 형식으로 변환할 수 있습니다(일반적으로 최종 사용자의 요청에 따라). 즉, 이진 표현이 기본입니다. 그리고 MQ에서는 트레이딩 서버 시간(심볼릭)을 기본으로 하는 것이 더 쉬울 것이라고 결정했습니다. 그리고 이것이 파슬리가 밝혀진 방법입니다. 예를 들어 이제 time_t == 100000이고 UTC+1 거래 서버는 103600에 새 막대에 서명하고 다른 UTC+2 무역 서버는 107200에 새 막대에 서명합니다. 즉. 같은 기간을 표시하는 막대는 datetame 필드에 다른 숫자가 있습니다. 얼핏보면 헛소리처럼 보입니다. 그러나 미국의 서버에서 유럽의 서버로 상태를 전송하려고 시도하십시오. 고정 시간만큼 어리석게 이동하면 일광 절약 시간제에서 /로의 전환이 다른 날에 발생하기 때문에 데이터가 일년에 두 번 퍼집니다. . 예를 들어 일부 서버는 시간을 SET에서 EET로 변경했습니다. 이제는 병 없이 교대 근무가 어디 있는지 확인하는 것이 불가능합니다.
네, 그게 당신이 말하는 것입니다. 여기서 질문은 간단합니다. 이 덕분에 MQ는 많은 CPU 시간을 절약했고 Amazon 포리스트 측면에서 실제로 다시 착륙했습니다.
거래에서 거래의 데이터 피드가 죽고 한 거래에서 다른 거래로 견적이 마이그레이션되지 않는다고 가정합니다. 원칙적으로 올바른 가정은 기쁨 따옴표가 한 DC에서 다른 DC로 전송된다는 것입니다.
MQ에서 수행한 작업(거래 시간에 바인딩)을 수행하지 않으면 데이터를 호출할 때마다 데이터가 현지 시간 으로 올바르게 표시되도록 변환(GMT 이동)해야 합니다. 그리고 데이터는 자주 읽혀지며 변환기는 각 읽기 호출에 대해 끊어야 합니다.
여기에서 질문은 이데올로기적이며, 단일 세계시로 전환하기 위해 빛의 지역일 또는 전 세계의 순환을 만들어야 하는지 여부입니다. 그리고 MQ는 프로메테안이 되기를 원하지 않고 단순히 시장을 따랐습니다. 시장은 미국인들이 아침 8시를 보기 위해 터미널에서 일어나기를 요구하고 유럽인들은 그것을 원한다.
따라서 거래에 대한 구속력은 논리적으로 보입니다. 또한 MQL5에는 GMT에 번역 기능이 있으므로 곧 mql4++에서도 사용할 수 있을 것으로 기대합니다.
그러나 당신의 유리와 독립에 대한 당신의 말은 실제로 개발을 늦추는 매몰 비용입니다. 그리고 MT5를 무시하는 것은 본질을 보지 못했고 MT4로 이미 기성품 개발이 있었기 때문입니다. MT5를 사용하면 훨씬 더 빠르고 더 아름다운 솔루션을 얻을 수 있습니다.
ECN을 유리라고 하면 대다수 기업이 필요로 하는 수정이 아니라 내가 필요한 수정을 신속하게 수행할 수 있기를 바랍니다. 나는 우리가 대부분의 다른 회사와 정반대의 이해 관계를 가지고 있음을 분명히 알 수 있습니다. 실행 시간 계산 등의 구현에 대한 발표가 있지만 희망을 주십시오.
유리 자체를 유리라고 부르면 몇 주 동안 작업이 있었습니다.
MT5가 더 낫다고 주장하는 것은 아닙니다. 제 자신도 그렇게 생각합니다. 하지만 MT5를 "보고" 시작했다면 지금은 훨씬 적은 수의 고객이 있을 것이라고 계속 믿습니다.
그리고 Alpari에서 다른 사람들의 개발이 너무 많이 실패한 후에 저는 매우 조심스럽습니다. 저는 회의론을 가지고 말하기까지 하며, 제 사업을 그들에게 맡기고 싶지 않습니다. 나는 당신이 개발자로서 나를 이해해야 한다고 확신합니다.
ECN을 유리라고 하면 대다수 기업이 필요로 하는 수정이 아니라 내가 필요한 수정을 신속하게 수행할 수 있기를 바랍니다. 나는 우리가 대부분의 다른 회사와 정반대의 이해 관계를 가지고 있음을 분명히 알 수 있습니다. 실행 시간 등의 계산의 구현에 대한 귀하의 발표가 있지만. 희망을 주십시오.
유리 자체를 유리라고 부르면 몇 주 동안 작업이 있었습니다.
MT5가 더 낫다고 주장하는 것은 아닙니다. 제 자신도 그렇게 생각합니다. 하지만 MT5를 "보고" 시작했다면 지금은 훨씬 적은 수의 고객이 있을 것이라고 계속 믿습니다.
그리고 Alpari에서 다른 사람들의 개발이 너무 많이 실패한 후에 저는 매우 조심스럽습니다. 저는 회의론을 가지고 말하기까지 하며, 제 사업을 그들에게 맡기고 싶지 않습니다. 나는 당신이 개발자로서 나를 이해해야 한다고 확신합니다.
즉, 중개업의 진정한 목적은 개발의 가려움으로 대체됩니다. 나는 가려움증이 정확히 똑같지만 나에게는 사업 방향과 완전히 일치합니다.
MT5의 주문서는 전체 시스템, 모든 게이트웨이, 프로세스, 전문가 등과 완전히 통합됩니다. 그리고 모든 MT5 브로커는 게이트웨이 연결 문제에서 완전히 자유롭습니다. 만약 그렇다면, 일반적이고 멋진 MetaTrader 5 Gateway API를 사용하여 게이트웨이를 작성하는 것이 훨씬 쉽습니다. 즉, 프로그래머의 가려움에 시간을 낭비할 필요가 없습니다.
그러나 어떤 사람들은 MT4를 계속 비판하고이 모든 것이 새싹에 고정 된 MT5를 보지 않습니다. 게다가 몇몇 중개인들은 이미 눈을 감고 ECN을 쓰기 위해 갔고 이제 그들은 무언가를 의심하기 시작했습니다.
즉, 중개업의 진정한 목적은 개발의 가려움으로 대체됩니다. 나는 가려움증이 정확히 똑같지만 나에게는 사업 방향과 완전히 일치합니다.
MT5의 주문서는 전체 시스템, 모든 게이트웨이, 프로세스, 전문가 등과 완전히 통합됩니다. 그리고 모든 MT5 브로커는 게이트웨이 연결 문제에서 완전히 자유롭습니다. 만약 그렇다면, 일반적이고 멋진 MetaTrader 5 Gateway API를 사용하여 게이트웨이를 작성하는 것이 훨씬 쉽습니다. 즉, 프로그래머의 가려움에 시간을 낭비할 필요가 없습니다.
그러나 어떤 사람들은 MT4를 계속 비판하고이 모든 것이 새싹에 고정 된 MT5를 보지 않습니다. 게다가 몇몇 중개인들은 이미 눈을 감고 ECN을 쓰기 위해 갔고 이제 그들은 무언가를 의심하기 시작했습니다.
그래서 당신은 자신이 시간대에 대한 문제를 만들었고, 이제 당신은 시간의 "표준"이 다른 세계와 다른 닫힌 공간을 만들고 있습니다.
포럼에서 반복적으로 언급했듯이 "거래자는 자신의 기록을 업로드할 것입니다".
데이터를 가져와 원하는 대로 가져오기만 하면 됩니다. 그러나 그 대신에 우리는 정확히 동일한 예상 주장을 봅니다. "어떻게 하든 상관없습니다. 긴장하지 않고 생각하지 않도록 이야기를 주세요." 즉, 여기에서도 MetaQuotes가 책임이 있습니다.
트레이더가 생각할 필요가 없도록 MetaTrader 5를 만들었습니다. MetaTrader 5는 플랫폼을 사용하기만 하면 10년 동안 M1의 정확도로 자세한 데이터가 어디서 오는지 생각조차 하지 않습니다.
그래서 당신은 자신이 시간대에 대한 문제를 만들었고, 이제 당신은 시간의 "표준"이 다른 세계와 다른 닫힌 공간을 만들고 있습니다.
그리고 더 자세하게, 무엇이 문제이고 폐쇄된 공간이 무엇인지 가능합니다.
모두가 알고 있듯이 datetime 변수에는 1970년 1월 1일 이후의 초가 포함됩니다. 00:00 분명히 이것은 유닉스 시간 형식의 프로토타입입니다. 그러나 원본 소스에 매우 중요한 설명이 있습니다. 00:00은 UTC 시간입니다. 그리고 동시에 모든 시간대의 모든 컴퓨터는 동일한 time_t 수치를 제공합니다. 저것들. time_t는 특정 시점을 고유하게 식별합니다. 그리고 time_t를 시간대에 따라 /에서 일광 절약 시간으로 전환하는 규칙에 따라 다른 방식으로 기호 형식으로 변환할 수 있습니다(일반적으로 최종 사용자의 요청에 따라). 즉, 이진 표현이 기본입니다. 그리고 MQ에서는 트레이딩 서버 시간(심볼릭)을 기본으로 하는 것이 더 쉬울 것이라고 결정했습니다. 그리고 이것이 파슬리가 밝혀진 방법입니다. 예를 들어 이제 time_t == 100000이고 UTC+1 거래 서버는 103600에 새 막대에 서명하고 다른 UTC+2 무역 서버는 107200에 새 막대에 서명합니다. 즉. 같은 기간을 표시하는 막대는 datetame 필드에 다른 숫자가 있습니다. 얼핏보면 헛소리처럼 보입니다. 그러나 미국의 서버에서 유럽의 서버로 상태를 전송하려고 시도하십시오. 고정 시간만큼 어리석게 이동하면 일광 절약 시간제에서 /로의 전환이 다른 날에 발생하기 때문에 데이터가 일년에 두 번 퍼집니다. . 예를 들어 일부 서버는 시간을 SET에서 EET로 변경했습니다. 이제는 병 없이 교대 근무가 어디 있는지 확인하는 것이 불가능합니다.
네, 그게 당신이 말하는 것입니다. 여기서 질문은 간단합니다. 이 덕분에 MQ는 많은 CPU 시간을 절약했고 Amazon 포리스트 측면에서 실제로 다시 착륙했습니다.
거래에서 거래의 데이터 피드가 죽고 한 거래에서 다른 거래로 견적이 마이그레이션되지 않는다고 가정합니다. 원칙적으로 올바른 가정은 기쁨 따옴표가 한 DC에서 다른 DC로 전송된다는 것입니다.
MQ에서 수행한 작업(거래 시간에 바인딩)을 수행하지 않으면 데이터를 호출할 때마다 데이터가 현지 시간 으로 올바르게 표시되도록 변환(GMT 이동)해야 합니다. 그리고 데이터는 자주 읽혀지며 변환기는 각 읽기 호출에 대해 끊어야 합니다.
여기에서 질문은 이데올로기적이며, 단일 세계시로 전환하기 위해 빛의 지역일 또는 전 세계의 순환을 만들어야 하는지 여부입니다. 그리고 MQ는 프로메테안이 되기를 원하지 않고 단순히 시장을 따랐습니다. 시장은 미국인들이 아침 8시를 보기 위해 터미널에서 일어나기를 요구하고 유럽인들은 그것을 원한다.
따라서 거래에 대한 구속력은 논리적으로 보입니다. 또한 MQL5에는 GMT에 번역 기능이 있으므로 곧 mql4++에서도 사용할 수 있을 것으로 기대합니다.
Renat :
그러나 당신의 유리와 독립에 대한 당신의 말은 실제로 개발을 늦추는 매몰 비용입니다. 그리고 MT5를 무시하는 것은 본질을 보지 못했고 MT4로 이미 기성품 개발이 있었기 때문입니다. MT5를 사용하면 훨씬 더 빠르고 더 아름다운 솔루션을 얻을 수 있습니다.
ECN을 유리라고 하면 대다수 기업이 필요로 하는 수정이 아니라 내가 필요한 수정을 신속하게 수행할 수 있기를 바랍니다. 나는 우리가 대부분의 다른 회사와 정반대의 이해 관계를 가지고 있음을 분명히 알 수 있습니다. 실행 시간 계산 등의 구현에 대한 발표가 있지만 희망을 주십시오.
유리 자체를 유리라고 부르면 몇 주 동안 작업이 있었습니다.
MT5가 더 낫다고 주장하는 것은 아닙니다. 제 자신도 그렇게 생각합니다. 하지만 MT5를 "보고" 시작했다면 지금은 훨씬 적은 수의 고객이 있을 것이라고 계속 믿습니다.
그리고 Alpari에서 다른 사람들의 개발이 너무 많이 실패한 후에 저는 매우 조심스럽습니다. 저는 회의론을 가지고 말하기까지 하며, 제 사업을 그들에게 맡기고 싶지 않습니다. 나는 당신이 개발자로서 나를 이해해야 한다고 확신합니다.
ECN을 유리라고 하면 대다수 기업이 필요로 하는 수정이 아니라 내가 필요한 수정을 신속하게 수행할 수 있기를 바랍니다. 나는 우리가 대부분의 다른 회사와 정반대의 이해 관계를 가지고 있음을 분명히 알 수 있습니다. 실행 시간 등의 계산의 구현에 대한 귀하의 발표가 있지만. 희망을 주십시오.
유리 자체를 유리라고 부르면 몇 주 동안 작업이 있었습니다.
MT5가 더 낫다고 주장하는 것은 아닙니다. 제 자신도 그렇게 생각합니다. 하지만 MT5를 "보고" 시작했다면 지금은 훨씬 적은 수의 고객이 있을 것이라고 계속 믿습니다.
그리고 Alpari에서 다른 사람들의 개발이 너무 많이 실패한 후에 저는 매우 조심스럽습니다. 저는 회의론을 가지고 말하기까지 하며, 제 사업을 그들에게 맡기고 싶지 않습니다. 나는 당신이 개발자로서 나를 이해해야 한다고 확신합니다.
즉, 중개업의 진정한 목적은 개발의 가려움으로 대체됩니다. 나는 가려움증이 정확히 똑같지만 나에게는 사업 방향과 완전히 일치합니다.
MT5의 주문서는 전체 시스템, 모든 게이트웨이, 프로세스, 전문가 등과 완전히 통합됩니다. 그리고 모든 MT5 브로커는 게이트웨이 연결 문제에서 완전히 자유롭습니다. 만약 그렇다면, 일반적이고 멋진 MetaTrader 5 Gateway API를 사용하여 게이트웨이를 작성하는 것이 훨씬 쉽습니다. 즉, 프로그래머의 가려움에 시간을 낭비할 필요가 없습니다.
그러나 어떤 사람들은 MT4를 계속 비판하고이 모든 것이 새싹에 고정 된 MT5를 보지 않습니다. 게다가 몇몇 중개인들은 이미 눈을 감고 ECN을 쓰기 위해 갔고 이제 그들은 무언가를 의심하기 시작했습니다.
즉, 중개업의 진정한 목적은 개발의 가려움으로 대체됩니다. 나는 가려움증이 정확히 똑같지만 나에게는 사업 방향과 완전히 일치합니다.
MT5의 주문서는 전체 시스템, 모든 게이트웨이, 프로세스, 전문가 등과 완전히 통합됩니다. 그리고 모든 MT5 브로커는 게이트웨이 연결 문제에서 완전히 자유롭습니다. 만약 그렇다면, 일반적이고 멋진 MetaTrader 5 Gateway API를 사용하여 게이트웨이를 작성하는 것이 훨씬 쉽습니다. 즉, 프로그래머의 가려움에 시간을 낭비할 필요가 없습니다.
그러나 어떤 사람들은 MT4를 계속 비판하고이 모든 것이 새싹에 고정 된 MT5를 보지 않습니다. 게다가 몇몇 중개인들은 이미 눈을 감고 ECN을 쓰기 위해 갔고 이제 그들은 무언가를 의심하기 시작했습니다.
MT5는 고객을 하나로 모으나요?
MT5는 고객을 하나로 모으나요?
우리가 대량 서비스에 집중하는 것은 헛된 것이 아닙니다. MetaTrader 5 Exchange Server에 관심을 가지십시오.
올 가을에 출시된 후 모든 맞춤형 ECN을 병합해야 합니다. 모든 브로커는 기본적으로 모든 MT5 제공자를 포함하여 대량의 게이트웨이 유동성 제공자를 완전하고 쉽게 통합하여 풀타임 ECN을 수신하기 때문입니다. 완전한 규칙 지향 일치를 포함합니다.
우리가 대량 서비스에 집중하는 것은 헛된 것이 아닙니다. MetaTrader 5 Exchange Server에 관심을 가지십시오.
올 가을에 출시된 후 모든 맞춤형 ECN을 병합해야 합니다. 모든 브로커는 기본적으로 모든 MT5 제공자를 포함하여 대량의 게이트웨이 유동성 제공자를 완전하고 쉽게 통합하여 풀타임 ECN을 수신하기 때문입니다. 완전한 규칙 지향 일치를 포함합니다.
저것들. 클라이언트가 서로 일치할 수 있습니까? 나는 많은 회사가 그러한 서비스를 선택하지 않을 것이라고 생각합니다. 매칭된 고객의 수입은 대부분의 사람들이 버는 것보다 약 4배 적습니다. 그리고 고객 기반이 클수록 일치하는 고객의 비율이 높아집니다.