정적 캐스팅이 무엇을 의미하는지 모르겠습니다. 시간대 문제는 mql의 고통입니다. 이전 mql4의 접근 방식은 사용자가 브로커 오프셋으로 설정한 전역 변수를 갖는 것이었으며, 새로운 timegmt 함수 를 사용하여 gmt 시간을 얻을 수도 있지만 이것이 버그가 있다는 보고를 일부 보았습니다. 또한 백 테스팅 중에 어떻게 동작하는지 잘 모르겠습니다. 불행히도 모든 것이 엉망입니다. 그러나 주변에서 코딩하는 것이 불가능한 것은 아닙니다.
ydrol, 성스러운 것이든 무엇이든 사랑하기 위해 mql4에서 static_cast를 사용할 수 있는지 알려주세요. C++에서와 동일합니까? 이 페이지 https://docs.mql4.com/basis/types/casting 은 이것을 언급하지 않으며 포럼에서 찾을 수 없으며 어디에서도 찾을 수 없습니다. 계속해서 코딩을 하다보면 datetime이 길어질 뿐만 아니라 datetime이 2배가 되는 불가피한 상황이 생겨서 제대로 해보고 싶습니다. 즉, 프로그램은 샘플이 어느 주의 어느 부분에 속하는지 파악하고 그에 따라 계산에서 강조합니다. 그러나 시간 모듈로 한 주의 초 수는 여전히 날짜/시간 유형 변수이며 다른 것으로 캐스팅할 수 없다면 그렇게 붙어 있습니다. 하지만 나는 그것의 수학적 기능을 수행할 필요가 있고, 마지막에 double이 되도록 해야 합니다. 모른다면 당황하지 말고 이런 상황에서 어떻게 타이핑을 해야 하는지 알려주세요.
문서에 데이터 유형 및 유형 변환에 대한 전체 섹션이 있습니다. 편집기를 사용하는 동안 F1 키를 누르십니까?
WHRoeder : 브로커 서버의 시간대입니다. 기간. mt4에서 얻은 모든 datetime은 서버의 시간대입니다. ( TimeLocal() 및 새로운 mt5 TimeGMT 제외 )
당신은 10 년 이상 된 것에 의아해합니까? Y2K라고 들어보셨나요? 그렇지 않다면 왜 날짜가 연도에 두 자리 숫자로만 저장되어 1999년 이후가 1900년 또는 19100년인지에 대해 의아해할 것입니다.
70억 인구의 세계에서 IP 주소가 42억으로 제한된 이유가 의아할 것입니다. 누군가 DARPA에서 그 나라의 기존(수십) 메인프레임 컴퓨터를 연결하려고 할 때 그런 결정을 내렸습니다. 이제 IPv4에서 IPv6으로 변환 중입니다.
자신을 극복하십시오. 이것은 Berger King이 아닙니다. 당신의 뜻대로 되지 않습니다. 누군가는 당시에는 합리적으로 보였지만 지금은 그렇지 않은 결정을 내렸습니다. 받아 들여.
아니, 당신은 자신을 극복합니다. 진지하게 나는 그것이 설계되었을 때 왜 그런 결정을 내렸는지 의아해합니다. 그리고 나는 그렇게 말할 권리가 있습니다. 언론의 자유와 그 모든 것. 당신은 나보다 더 이상 나를 억압하려고 할 권리가 없습니다. 이미 utc를 사용한 확립된 시간 형식을 기반으로 하며 10년이 훨씬 넘었습니다. 이제 mql4에는 솔직히 말해서 당혹스러운 결정으로 인해 시간대 문제가 있습니다. 그리고 나는 그렇게 말할 수 있습니다. 당신은 y2k에 대해 당신이 원하는 모든 것에 대해 얼굴을 찡그릴 수 있습니다. 그것은 차이가 없습니다. 저는 거의 20년 동안 시스템 통합 분야에서 일했고 그것을 utc로 수정하지 않는 것은 잘못된 설계 결정처럼 보입니다. 다른 사람이 자신의 의견을 말하는 것을 처리할 수 없다면 죄송합니다.
현재 TimeZone/Session 기능을 깔끔한 mql4++ 클래스로 마이그레이션하고 있기 때문에 이것을 다시 준설합니다!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
나는 그것을 다루고 있지만, 나는 여전히 왜 내가 먼저해야하는지 의아해합니다! 시간대 정보 관리에 대한 모범 사례는 오랫동안 존재해 왔습니다. 1988년부터. 예: ISO 8601
ISO 8601의 표준 시간대 는 현지 시간(위치가 지정되지 않음), UTC 또는 UTC와의 오프셋으로 표시됩니다.
시간 표현과 함께 UTC 관계 정보가 제공되지 않으면 시간은 현지 시간으로 간주됩니다. 동일한 시간대에서 통신할 때 현지 시간을 가정하는 것이 안전할 수 있지만 다른 시간대 간에 통신하는 경우 모호합니다 . [My 강조] 일반적으로 표준 표기법을 사용하여 시간대(zone 지정자)를 표시하는 것이 좋습니다. ."
밑줄 친 부분은 IT에서 거의 30년 동안 알려져 왔습니다. MQL 날짜/시간 형식은 UnixTime에서 파생되었으므로(1970년 1월 1일 마법의 날짜를 공중에서 뽑지 않았습니다) 지금 알고 있어야 합니다.
1988년에 다시 POSIX는 UnixTime을 비준했습니다.
"POSIX 위원회는 라이브러리 기능의 복잡성에 대한 논쟁에 휘둘렸고, UTC 시간의 요소에 대해 간단 하게 유닉스 시간을 확고히 정의했습니다. [내 강조]
시간이 중요한 정보를 교환하는 10년 전 클라이언트-서버 시스템을 설계하는 시스템 설계자 또는 개발자는 현재 시간대 혼란을 예상/피할 수 있는 충분한 정보를 가지고 있어야 합니다. 한 시간대의 거래자는 다른 시간대(예: NY)에서 해석되기를 원하는 다른 시간대의 데이터를 얻습니다. 유일한 변명은 다음과 같습니다.
- 무지
- 낮은 우선순위(TZ 혼란은 거래자가 아닌 중개인에게 이익이 되나요?)
- 외부에서 우리에게 명확하지 않은 일부 기술적 고려 사항/제약 사항/요구 사항. 차트나 뭔가를 그리나요? 알려진 오프셋을 더하거나 빼기가 그렇게 어렵지는 않지만?
앞서 말했듯이 위의 모든 것이 나를 어리둥절하게 합니다. 백테스팅 동안 GMT 시간을 계산하기 위해 코드를 작성할 필요가 없다고 생각합니다! 그러나 TimeGMT() 및 TimeLocal()은 올바르게 모델링되지 않았습니다(둘 다 과거 데이터에서 파생된 비특정 TZ로 설정됨). 따라서 UTC와 세션 시작 및 종료 시간을 정확하게 계산하기 위해 자체 시간대 함수의 역할을 수행해야 합니다. 백테스트 중.
10년이 넘은 것에 의아해합니까? Y2K라고 들어보셨나요? 그렇지 않다면 왜 날짜가 연도에 두 자리 숫자로만 저장되어 1999년 이후가 1900년 또는 19100년인지에 대해 의아해할 것입니다.
70억 인구의 세계에서 IP 주소가 42억으로 제한된 이유가 의아할 것입니다. 누군가 DARPA에서 그 나라의 기존(수십) 메인프레임 컴퓨터를 연결하려고 할 때 그런 결정을 내렸습니다. 이제 IPv4에서 IPv6으로 변환 중입니다.
자신을 극복하십시오. 이것은 Berger King이 아닙니다. 당신의 뜻대로 되지 않습니다. 누군가는 당시에는 합리적으로 보였지만 지금은 그렇지 않은 결정을 내렸습니다. 받아 들여.
ydrol, 성스러운 것이든 무엇이든 사랑하기 위해 mql4에서 static_cast를 사용할 수 있는지 알려주세요. C++에서와 동일합니까? 이 페이지 https://docs.mql4.com/basis/types/casting 은 이것을 언급하지 않으며 포럼에서 찾을 수 없으며 어디에서도 찾을 수 없습니다. 계속해서 코딩을 하다보면 datetime이 길어질 뿐만 아니라 datetime이 2배가 되는 불가피한 상황이 생겨서 제대로 해보고 싶습니다. 즉, 프로그램은 샘플이 어느 주의 어느 부분에 속하는지 파악하고 그에 따라 계산에서 강조합니다. 그러나 시간 모듈로 한 주의 초 수는 여전히 날짜/시간 유형 변수이며 다른 것으로 캐스팅할 수 없다면 그렇게 붙어 있습니다. 하지만 나는 그것의 수학적 기능을 수행할 필요가 있고, 마지막에 double이 되도록 해야 합니다. 모른다면 당황하지 말고 이런 상황에서 어떻게 타이핑을 해야 하는지 알려주세요.
문서에 데이터 유형 및 유형 변환에 대한 전체 섹션이 있습니다. 편집기를 사용하는 동안 F1 키를 누르십니까?
브로커 서버의 시간대입니다. 기간. mt4에서 얻은 모든 datetime은 서버의 시간대입니다. ( TimeLocal() 및 새로운 mt5 TimeGMT 제외 )
당신은 10 년 이상 된 것에 의아해합니까? Y2K라고 들어보셨나요? 그렇지 않다면 왜 날짜가 연도에 두 자리 숫자로만 저장되어 1999년 이후가 1900년 또는 19100년인지에 대해 의아해할 것입니다.
70억 인구의 세계에서 IP 주소가 42억으로 제한된 이유가 의아할 것입니다. 누군가 DARPA에서 그 나라의 기존(수십) 메인프레임 컴퓨터를 연결하려고 할 때 그런 결정을 내렸습니다. 이제 IPv4에서 IPv6으로 변환 중입니다.
자신을 극복하십시오. 이것은 Berger King이 아닙니다. 당신의 뜻대로 되지 않습니다. 누군가는 당시에는 합리적으로 보였지만 지금은 그렇지 않은 결정을 내렸습니다. 받아 들여.
브로커 서버의 시간대입니다. 기간. mt4에서 얻은 모든 datetime은 서버의 시간대입니다. ( TimeLocal() 및 새로운 mt5 TimeGMT 제외 .
현재 TimeZone/Session 기능을 깔끔한 mql4++ 클래스로 마이그레이션하고 있기 때문에 이것을 다시 준설합니다!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
나는 그것을 다루고 있지만, 나는 여전히 왜 내가 먼저해야하는지 의아해합니다! 시간대 정보 관리에 대한 모범 사례는 오랫동안 존재해 왔습니다. 1988년부터. 예: ISO 8601
ISO 8601의 표준 시간대 는 현지 시간(위치가 지정되지 않음), UTC 또는 UTC와의 오프셋으로 표시됩니다.
시간 표현과 함께 UTC 관계 정보가 제공되지 않으면 시간은 현지 시간으로 간주됩니다. 동일한 시간대에서 통신할 때 현지 시간을 가정하는 것이 안전할 수 있지만 다른 시간대 간에 통신하는 경우 모호합니다 . [My 강조] 일반적으로 표준 표기법을 사용하여 시간대(zone 지정자)를 표시하는 것이 좋습니다. ."
밑줄 친 부분은 IT에서 거의 30년 동안 알려져 왔습니다. MQL 날짜/시간 형식은 UnixTime에서 파생되었으므로(1970년 1월 1일 마법의 날짜를 공중에서 뽑지 않았습니다) 지금 알고 있어야 합니다.
1988년에 다시 POSIX는 UnixTime을 비준했습니다.
"POSIX 위원회는 라이브러리 기능의 복잡성에 대한 논쟁에 휘둘렸고, UTC 시간의 요소에 대해 간단 하게 유닉스 시간을 확고히 정의했습니다. [내 강조]
시간이 중요한 정보를 교환하는 10년 전 클라이언트-서버 시스템을 설계하는 시스템 설계자 또는 개발자는 현재 시간대 혼란을 예상/피할 수 있는 충분한 정보를 가지고 있어야 합니다. 한 시간대의 거래자는 다른 시간대(예: NY)에서 해석되기를 원하는 다른 시간대의 데이터를 얻습니다. 유일한 변명은 다음과 같습니다.
- 무지
- 낮은 우선순위(TZ 혼란은 거래자가 아닌 중개인에게 이익이 되나요?)
- 외부에서 우리에게 명확하지 않은 일부 기술적 고려 사항/제약 사항/요구 사항. 차트나 뭔가를 그리나요? 알려진 오프셋을 더하거나 빼기가 그렇게 어렵지는 않지만?
앞서 말했듯이 위의 모든 것이 나를 어리둥절하게 합니다. 백테스팅 동안 GMT 시간을 계산하기 위해 코드를 작성할 필요가 없다고 생각합니다! 그러나 TimeGMT() 및 TimeLocal()은 올바르게 모델링되지 않았습니다(둘 다 과거 데이터에서 파생된 비특정 TZ로 설정됨). 따라서 UTC와 세션 시작 및 종료 시간을 정확하게 계산하기 위해 자체 시간대 함수의 역할을 수행해야 합니다. 백테스트 중.
추신: WHRoeder가 "나 자신을 극복하라"는 아이러니는 잃지 않았습니다. :)