어떻게 하면 MT4를 더 적절하게 만들 수 있습니까? 나는 당신에 대해 모르지만 나는 지역 역사적 GMT 오프셋 계산기를 만드는 작업을 좋아하지 않을 것입니다. 당신은 단지 상상할 수 있습니까? 어머나. 내가 할 수 있다면 시장에 내놓을 것입니다. 큰 수표 책을 가지고 계시는 것이 좋습니다. ;)
과거 GMT 계산기 자체는 특별히 어렵지 않지만(Windows 운영 체제에는 필요한 모든 데이터가 이미 포함되어 있음) 주요 문제는 아닙니다. 문제는 브로커 시간과 GMT 사이의 현재 오프셋을 확인할 수 있지만 변경되었는지 여부는 알 수 없다는 것입니다. 위의 예를 사용하면 브로커가 현재 GMT+3에 있음을 알 수 있지만(로컬 컴퓨터 시계가 정확하다고 가정할 때...), 브로커가 지난 주에 GMT+2에 있었다는 것을 알지 못합니다.
MT4 클라이언트 터미널에 이 정보가 없을 가능성이 매우 높습니다.
그것이 있었다면 MT4 는 스스로 처리할 수 있는 베어 데이터나 "과거의 모든 브로커 날짜를 GMT로 변환"이라고 말할 수 있는 기능 을 제공할 수 있습니다. 일단 가지고 있으면 조회 테이블(또는 Windows API)을 사용하여 역사적인 GMT 시간을 런던과 같은 다른 시간대로 변환할 수 있습니다. 그러나 MT4가 이 작업도 수행하는 것이 좋습니다(예: 다음과 같은 한 쌍의 기능).
날짜 시간 ConvertToBrokerTime(날짜 시간 HistoricalRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);
날짜 시간 ConvertFromBrokerTime(날짜 시간 HistoricalBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);
다른 접근 방식, 이 페이지 에 따르면 MT4 중개인은 62명뿐입니까? 따라서 각 브로커에 대한 조회 테이블과 시간 정의(실제 시간대를 기반으로 하는지 또는 FXCM의 조합을 기반으로 하는지 여부)와 과거 변경 사항(Alpari)을 통합하는 것은 그리 어렵지 않을 것입니다.
이것은 아마도 가장 강력한 접근 방식일 것이며 브로커가 클라이언트를 조금 더 혼란스럽게 하기를 원한다고 결정할 때마다 조정이 필요할 것입니다. :)
[1] GMT+3의 서버 시간은 EEST가 GMT+3이라는 점에서 EEST에 해당할 수 있지만 Wikipedia와 worldclock.com에 따르면 아직 EEST에 있는 곳이 없습니다. 이 변경 사항은 3월 30일까지 발생해서는 안 됩니다. 키프로스, 그리스, 이스라엘 등의 현재 시간은 GMT+2입니다.
[2] 따라서 아마도 GMT+2에서 서버를 실행하지만 유럽 날짜가 아닌 미국 날짜에 일광 절약 시간제로 변경하는 브로커가 있을 것입니다.
[3] EET/EEST와 다릅니다. (그리고 브로커가 사용하는 시간 설정에 대한 입력을 사용자에게 묻지 않고도 시간과 날짜를 자동으로 조정하는 코드를 작성할 수 있다는 점에서 예측하기가 훨씬 어렵습니다.)
옳은.
옳은.
EET는 GMT+2이지만 GMT+2는 EET만이 아닙니다. 또한 EEST는 GMT+3이지만 GMT+3은 EEST만이 아닙니다. 내 브로커의 시간대를 EET/EEST로 설명함으로써, 특히 이 스레드가 런던 브레이크아웃에 대해 논의하기 때문에 표준 시간에는 GMT+2이고 일광 절약 시간에는 GMT+3이라는 것을 유추하려고 했습니다. 제 설명이 혼란을 드린 점 사과드립니다. :)
따라서 브로커가 GMT+3에서 GMT+4로 변경될 예정이 아니라 최근에 GMT+2에서 GMT+3으로 변경된 경우 이는 브로커 시간과 GMT 사이의 현재 오프셋이 잘못된 경우 미국 시계가 바뀌기 전 지난 주에 막대에 적용하려고 했습니다. 이번 주 중개인의 바는 런던보다 3시간 빠릅니다. 지난 주에는 2시간 앞서 있었습니다. (그리고 3월 30일부터는 다시 2시간 앞당겨집니다.) 3시간의 현재 오프셋을 사용하여 지난 주 런던 시간 오전 8시에 가격을 구하려고 하면 오답이 나옵니다. .
브로커는 일반적으로 일광 절약 시간제 조정을 제외하고 서버의 시간대를 자주 변경하지 않습니다. 일광 절약 시간 조정의 경우 모든 날짜/시간(1987(US) 및 1996(EU)부터 2020년 이후까지)을 사용할 수 있으며 미국 및 EU의 경우 일광 절약 시간제가 시작되고 일광 시간 절약이 종료됩니다. 해당 코드가 있으면 보고 있는 시간의 일광 절약 시간제를 수용하도록 현재 오프셋을 GMT로 조정하기만 하면 됩니다.
빌드 600+의 새로운 기능인 TimeGMT()를 사용하여 중개인의 현재 GMT 오프셋을 계산합니다. 그러나 내가 아는 한 과거에서 브로커의 시간대를 결정할 수는 없습니다. 예를 들어, 브로커가 표준 시간의 경우 GMT에서 표준 시간의 경우 GMT+2로 서버의 시간대를 변경하도록 했습니다. 모든 기록 데이터가 GMT+2가 아니라 GMT였기 때문에 전환 전 시간에 대한 오프셋을 하드 코딩하여 처리했습니다(GMT+2를 반영하도록 기록을 수정하고 싶지 않았습니다). 그런 점에서 나는 당신과 나는 동의합니다. 브로커가 시간대를 변경하지 않는 한(일광 절약 시간 조정 제외), GMT에 대한 오프셋을 계산하고 일광 절약 시간에 대한 오프셋을 조정할 수 있어야 합니다.
내가 말하고자 하는 것은 MT4 자체에서 얻을 수 있는 정보(브로커 시간과 GMT 사이의 현재 오프셋)가 실제로 "지난 수요일 런던 시가를 계산하세요"와 같은 작업을 수행하는 데 부적절하다는 것입니다.
나는 당신과 동의하지 않는다고 믿습니다. 브로커가 일광 절약 시간제 조정을 제외하고 시간대를 변경하지 않는 한 현재 시간 과 과거 시간 모두에 대해 GMT에 대한 오프셋을 결정할 수 있습니다. 지난 주 표준시 중 브로커가 GMT+2이고 런던이 GMT인 경우 런던 시간 오전 8시가 서버 시간 오전 10시가 됩니다. 다음 달 일광 절약 시간 동안 브로커가 GMT+3이고 런던이 GMT+1일 때 런던 시간 오전 8시는 서버 시간 오전 10시에 해당합니다. 오늘날 브로커가 일광 절약 시간제에 있고 런던이 표준 시간일 때 브로커는 GMT+3이고 런던은 GMT이므로 런던 시간 오전 8시는 서버 시간 오전 11시가 됩니다.
브로커가 GMT-5(EST)이고 런던이 GMT인 경우 런던 시간 오전 8시는 서버 시간 오전 3시입니다.
과거 GMT 계산기 자체는 특별히 어렵지 않지만(Windows 운영 체제에는 필요한 모든 데이터가 이미 포함되어 있음) 주요 문제는 아닙니다. 문제는 브로커 시간과 GMT 사이의 현재 오프셋을 확인할 수 있지만 변경되었는지 여부는 알 수 없다는 것입니다. 위의 예를 사용하면 브로커가 현재 GMT+3에 있음을 알 수 있지만(로컬 컴퓨터 시계가 정확하다고 가정할 때...), 브로커가 지난 주에 GMT+2에 있었다는 것을 알지 못합니다.
MT4 클라이언트 터미널에 이 정보가 없을 가능성이 매우 높습니다.
그것이 있었다면 MT4 는 스스로 처리할 수 있는 베어 데이터나 "과거의 모든 브로커 날짜를 GMT로 변환"이라고 말할 수 있는 기능을 제공할 수 있습니다. 일단 가지고 있으면 조회 테이블(또는 Windows API)을 사용하여 역사적인 GMT 시간을 런던과 같은 다른 시간대로 변환할 수 있습니다. 그러나 MT4가 이 작업도 수행하는 것이 좋습니다(예: 다음과 같은 한 쌍의 기능).
날짜 시간 ConvertToBrokerTime(날짜 시간 HistoricalRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);
날짜 시간 ConvertFromBrokerTime(날짜 시간 HistoricalBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);
네, DST가 없다면 어렵지 않을 것입니다. 그러나 LOL이 있습니다. 코딩하는 것은 악몽일 것입니다. 역사적 변칙성은 어디에나 있을 것입니다. 사용하는 시간대를 변경한 지역, DST를 전혀 사용하지 않는 실험을 했다가 다시 DST로 되돌린 지역, 일부 지역에서는 DST를 존중하지만 다른 지역에서는 적용하지 않는 지역은 전 세계적으로 고려해야 할 변칙이 너무 많습니다. ..
다른 접근 방식, 이 페이지 에 따르면 MT4 중개인은 62명뿐입니까? 따라서 각 브로커에 대한 조회 테이블과 시간 정의(실제 시간대를 기반으로 하는지 또는 FXCM의 조합을 기반으로 하는지 여부)와 과거 변경 사항(Alpari)을 통합하는 것은 그리 어렵지 않을 것입니다.
네, 모두 IMO 의 난해한 디자인 결정 때문입니다. :) 따라서 서버 시간은 1년 동안 알려진 세계 시계와 일치하지 않을 수도 있습니다.
백 테스팅 중에 GMT 시간을 정확하게 결정하는 한 가지 방법이 있습니다. 이 방법은 다음과 같은 브로커에게 작동하는 것으로 보입니다.
그러나 그 접근 방식은 여전히 나에게 약간 엉뚱하게 느껴진다.
여기에는 다른 출처(dukascopy)에서 GMT 기반 시세를 다운로드하고 각 일일 최고 시간을 비교하는 작업이 포함되었습니다. 백테스팅에는 문제가 없지만 현재 수동으로 시간 데이터를 다운로드하고 최고값을 필터링하고 있습니다(perl 스크립트 사용).
최소한 두 곳의 출처에서 GMT H1 견적을 자동으로 얻을 수 있게 되면 이 접근 방식이 제 목적에 적합할 것입니다.
어떻게 하면 MT4를 더 적절하게 만들 수 있습니까? 나는 당신에 대해 모르지만 나는 지역 역사적 GMT 오프셋 계산기를 만드는 작업을 좋아하지 않을 것입니다. 당신은 단지 상상할 수 있습니까? 어머나. 내가 할 수 있다면 시장에 내놓을 것입니다. 큰 수표 책을 가지고 계시는 것이 좋습니다. ;)
과거 GMT 계산기 자체는 특별히 어렵지 않지만(Windows 운영 체제에는 필요한 모든 데이터가 이미 포함되어 있음) 주요 문제는 아닙니다. 문제는 브로커 시간과 GMT 사이의 현재 오프셋을 확인할 수 있지만 변경되었는지 여부는 알 수 없다는 것입니다. 위의 예를 사용하면 브로커가 현재 GMT+3에 있음을 알 수 있지만(로컬 컴퓨터 시계가 정확하다고 가정할 때...), 브로커가 지난 주에 GMT+2에 있었다는 것을 알지 못합니다.
MT4 클라이언트 터미널에 이 정보가 없을 가능성이 매우 높습니다.
그것이 있었다면 MT4 는 스스로 처리할 수 있는 베어 데이터나 "과거의 모든 브로커 날짜를 GMT로 변환"이라고 말할 수 있는 기능 을 제공할 수 있습니다. 일단 가지고 있으면 조회 테이블(또는 Windows API)을 사용하여 역사적인 GMT 시간을 런던과 같은 다른 시간대로 변환할 수 있습니다. 그러나 MT4가 이 작업도 수행하는 것이 좋습니다(예: 다음과 같은 한 쌍의 기능).
날짜 시간 ConvertToBrokerTime(날짜 시간 HistoricalRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);
날짜 시간 ConvertFromBrokerTime(날짜 시간 HistoricalBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);
네, 모두 IMO 의 난해한 디자인 결정 때문입니다 :)
(UTC에 고정하지 않는 이유는 브로커가 EET에서 매주 5개의 D1 양초를 제공하여 GMTZ를 사용하는 브로커에 대한 D1 ATR과 같은 것을 체계적으로 과소평가하는 여섯 번째 작은 양초를 피할 수 있도록 하기 위함이라고 가정합니다.)
나는 그 모든 것을 클라이언트에 넣었을 것이지만 클라이언트를 다른 위치에서 더 복잡하게 만듭니다. :) 그러나 적어도 모든 변수는 알려져 있습니다.
다른 접근 방식, 이 페이지 에 따르면 MT4 중개인은 62명뿐입니까? 따라서 각 브로커에 대한 조회 테이블과 시간 정의(실제 시간대를 기반으로 하는지 또는 FXCM의 조합을 기반으로 하는지 여부)와 과거 변경 사항(Alpari)을 통합하는 것은 그리 어렵지 않을 것입니다.
이것은 아마도 가장 강력한 접근 방식일 것이며 브로커가 클라이언트를 조금 더 혼란스럽게 하기를 원한다고 결정할 때마다 조정이 필요할 것입니다. :)
gchrmt4 :
[1] GMT+3의 서버 시간은 EEST가 GMT+3이라는 점에서 EEST에 해당할 수 있지만 Wikipedia와 worldclock.com에 따르면 아직 EEST에 있는 곳이 없습니다. 이 변경 사항은 3월 30일까지 발생해서는 안 됩니다. 키프로스, 그리스, 이스라엘 등의 현재 시간은 GMT+2입니다.
[2] 따라서 아마도 GMT+2에서 서버를 실행하지만 유럽 날짜가 아닌 미국 날짜에 일광 절약 시간제로 변경하는 브로커가 있을 것입니다.
[3] EET/EEST와 다릅니다. (그리고 브로커가 사용하는 시간 설정에 대한 입력을 사용자에게 묻지 않고도 시간과 날짜를 자동으로 조정하는 코드를 작성할 수 있다는 점에서 예측하기가 훨씬 어렵습니다.)
브로커는 일반적으로 일광 절약 시간제 조정을 제외하고 서버의 시간대를 자주 변경하지 않습니다. 일광 절약 시간 조정의 경우 모든 날짜/시간(1987(US) 및 1996(EU)부터 2020년 이후까지)을 사용할 수 있으며 미국 및 EU의 경우 일광 절약 시간제가 시작되고 일광 시간 절약이 종료됩니다. 해당 코드가 있으면 보고 있는 시간의 일광 절약 시간제를 수용하도록 현재 오프셋을 GMT로 조정하기만 하면 됩니다.
빌드 600+의 새로운 기능인 TimeGMT()를 사용하여 중개인의 현재 GMT 오프셋을 계산합니다. 그러나 내가 아는 한 과거에서 브로커의 시간대를 결정할 수는 없습니다. 예를 들어, 브로커가 표준 시간의 경우 GMT에서 표준 시간의 경우 GMT+2로 서버의 시간대를 변경하도록 했습니다. 모든 기록 데이터가 GMT+2가 아니라 GMT였기 때문에 전환 전 시간에 대한 오프셋을 하드 코딩하여 처리했습니다(GMT+2를 반영하도록 기록을 수정하고 싶지 않았습니다). 그런 점에서 나는 당신과 나는 동의합니다. 브로커가 시간대를 변경하지 않는 한(일광 절약 시간 조정 제외), GMT에 대한 오프셋을 계산하고 일광 절약 시간에 대한 오프셋을 조정할 수 있어야 합니다.
내가 말하고자 하는 것은 MT4 자체에서 얻을 수 있는 정보(브로커 시간과 GMT 사이의 현재 오프셋)가 실제로 "지난 수요일 런던 시가를 계산하세요"와 같은 작업을 수행하는 데 부적절하다는 것입니다.
나는 당신과 동의하지 않는다고 믿습니다. 브로커가 일광 절약 시간제 조정을 제외하고 시간대를 변경하지 않는 한 현재 시간 과 과거 시간 모두에 대해 GMT에 대한 오프셋을 결정할 수 있습니다. 지난 주 표준시 중 브로커가 GMT+2이고 런던이 GMT인 경우 런던 시간 오전 8시가 서버 시간 오전 10시가 됩니다. 다음 달 일광 절약 시간 동안 브로커가 GMT+3이고 런던이 GMT+1일 때 런던 시간 오전 8시는 서버 시간 오전 10시에 해당합니다. 오늘날 브로커가 일광 절약 시간제에 있고 런던이 표준 시간일 때 브로커는 GMT+3이고 런던은 GMT이므로 런던 시간 오전 8시는 서버 시간 오전 11시가 됩니다.
브로커가 GMT-5(EST)이고 런던이 GMT인 경우 런던 시간 오전 8시는 서버 시간 오전 3시입니다.
과거 GMT 계산기 자체는 특별히 어렵지 않지만(Windows 운영 체제에는 필요한 모든 데이터가 이미 포함되어 있음) 주요 문제는 아닙니다. 문제는 브로커 시간과 GMT 사이의 현재 오프셋을 확인할 수 있지만 변경되었는지 여부는 알 수 없다는 것입니다. 위의 예를 사용하면 브로커가 현재 GMT+3에 있음을 알 수 있지만(로컬 컴퓨터 시계가 정확하다고 가정할 때...), 브로커가 지난 주에 GMT+2에 있었다는 것을 알지 못합니다.
MT4 클라이언트 터미널에 이 정보가 없을 가능성이 매우 높습니다.
그것이 있었다면 MT4 는 스스로 처리할 수 있는 베어 데이터나 "과거의 모든 브로커 날짜를 GMT로 변환"이라고 말할 수 있는 기능을 제공할 수 있습니다. 일단 가지고 있으면 조회 테이블(또는 Windows API)을 사용하여 역사적인 GMT 시간을 런던과 같은 다른 시간대로 변환할 수 있습니다. 그러나 MT4가 이 작업도 수행하는 것이 좋습니다(예: 다음과 같은 한 쌍의 기능).
날짜 시간 ConvertToBrokerTime(날짜 시간 HistoricalRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);
날짜 시간 ConvertFromBrokerTime(날짜 시간 HistoricalBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);
네, DST가 없다면 어렵지 않을 것입니다. 그러나 LOL이 있습니다. 코딩하는 것은 악몽일 것입니다. 역사적 변칙성은 어디에나 있을 것입니다. 사용하는 시간대를 변경한 지역, DST를 전혀 사용하지 않는 실험을 했다가 다시 DST로 되돌린 지역, 일부 지역에서는 DST를 존중하지만 다른 지역에서는 적용하지 않는 지역은 전 세계적으로 고려해야 할 변칙이 너무 많습니다. ..
다른 접근 방식, 이 페이지 에 따르면 MT4 중개인은 62명뿐입니까? 따라서 각 브로커에 대한 조회 테이블과 시간 정의(실제 시간대를 기반으로 하는지 또는 FXCM의 조합을 기반으로 하는지 여부)와 과거 변경 사항(Alpari)을 통합하는 것은 그리 어렵지 않을 것입니다.
Thirteen :
지난주 표준시 중 브로커가 GMT+2이고 런던이 GMT인 경우
상식적인 접근 방식은 MT4 서버가 항상 GMT를 사용하는 것이지만 그렇게 하지 않을 것이라는 것을 알고 있습니다.