MT4のEAバックテストでサマータイムを正確に計算する
2017年4月1日
MT4でEAのプログラミングをしていると、困るのが「夏時間の判定」です。こんな記事も書いているくらいです。
たいてい、MT4を扱っているFX業者のタイムゾーンはGMT+2、ニューヨークの夏時間に合わせてGMT+3になります。このように扱うと週の日足が5本になり簡便になりますからね。
EAのアルゴリズムで日本時間を用いている場合、夏時間を考慮に入れなければなりません。例えばこのようなケースです。
- 日本時間早朝に押し目買いを狙う「朝スキャ」
- ゴトー日仲値直前のドル円の上昇とその後の下降を狙う
- 日本市場が閉じる直前の逆張りを狙う
最後の戦略はこちらの本で提唱されている戦略ですね。
このような戦略のときには、夏時間の判定を正確に反映しなければならないのですが、MT4では夏時間の判定がなかなか厄介です。
MT4プログラムの小ネタ アメリカ夏時間を判定するプログラムというものもありますが、こちらはバックテストでは動きません。バックテストではMT4標準でGMTを取得する関数TimeGMT()が機能しないからです。
fx-onなどで販売されているEAを見ても、正確に夏時間を反映してバックテストしているプログラムが見当たらないようだったので、、人力で作ってみました。
力づくで夏時間を判定する
今回は力技で夏時間を判定しています。かなりアホなプログラムです笑
そもそもニューヨーク夏時間は、現地時間で「3月第2日曜日午前2時〜11月第1日曜日午前2時」と決められています。
ですので、TimeCurrent()で取得したサーバー時刻がこの範囲内なら夏時間、ということですね。しかもFXなので土日は考慮しなくて良いですから、このようなクソコードで判定できます。
bool IsSummerTime(){ //3月第2日曜日午前2時〜11月第1日曜日午前2時 switch(Year()){ case 2005: if(StringToTime("2005.3.13")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2005.11.6"))return true; break; case 2006: if(StringToTime("2006.3.12")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2006.11.5"))return true; break; case 2007: if(StringToTime("2007.3.11")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2007.11.4"))return true; break; case 2008: if(StringToTime("2008.3.9") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2008.11.2"))return true; break; case 2009: if(StringToTime("2009.3.8") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2009.11.1"))return true; break; case 2010: if(StringToTime("2010.3.14")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2010.11.7"))return true; break; case 2011: if(StringToTime("2011.3.13")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2011.11.6"))return true; break; case 2012: if(StringToTime("2012.3.11")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2012.11.4"))return true; break; case 2013: if(StringToTime("2013.3.10")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2013.11.3"))return true; break; case 2014: if(StringToTime("2014.3.9") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2014.11.2"))return true; break; case 2015: if(StringToTime("2015.3.8") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2015.11.1"))return true; break; case 2016: if(StringToTime("2016.3.13")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2016.11.6"))return true; break; case 2017: if(StringToTime("2017.3.12")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2017.11.5"))return true; break; case 2018: if(StringToTime("2018.3.11")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2018.11.4"))return true; break; case 2019: if(StringToTime("2019.3.10")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2019.11.3"))return true; break; case 2020: if(StringToTime("2020.3.8") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2020.11.1"))return true; break; case 2021: if(StringToTime("2021.3.14")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2021.11.7"))return true; break; case 2022: if(StringToTime("2022.3.13")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2022.11.6"))return true; break; case 2023: if(StringToTime("2023.3.12")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2023.11.5"))return true; break; case 2024: if(StringToTime("2024.3.10")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2024.11.3"))return true; break; case 2025: if(StringToTime("2025.3.9") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2025.11.2"))return true; break; case 2026: if(StringToTime("2026.3.8") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2026.11.1"))return true; break; case 2027: if(StringToTime("2027.3.14")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2027.11.7"))return true; break; case 2028: if(StringToTime("2028.3.12")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2028.11.5"))return true; break; case 2029: if(StringToTime("2029.3.11")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2029.11.4"))return true; break; case 2030: if(StringToTime("2030.3.10")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2030.11.3"))return true; break; case 2031: if(StringToTime("2031.3.9") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2031.11.2"))return true; break; case 2032: if(StringToTime("2032.3.14")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2032.11.7"))return true; break; case 2033: if(StringToTime("2033.3.13")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2033.11.6"))return true; break; case 2034: if(StringToTime("2034.3.12")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2034.11.5"))return true; break; case 2035: if(StringToTime("2035.3.11")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2035.11.4"))return true; break; case 2036: if(StringToTime("2036.3.9") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2036.11.2"))return true; break; case 2037: if(StringToTime("2037.3.8") <=TimeCurrent()&&TimeCurrent()<=StringToTime("2037.11.1"))return true; break; case 2038: if(StringToTime("2038.3.14")<=TimeCurrent()&&TimeCurrent()<=StringToTime("2038.11.7"))return true; break; } return false; }
上記、見たまんまですが、switch文で年を判定し、あとは月日からサマータイムか否かを判定しています。2005年から2038年まで対応しています。
もちろん、もっと簡便なコードにすることも可能です。この期間のカレンダーのパターンは7パターンしかありませんので。
Posted by auto-ts.net
関連記事
日本時間、GMT、GMT+2、夏時間ごとの時刻早見表
EAを作成していると、時折悩むのが時間帯問題です。 なにせ、日本時間とヨーロッパ ...
有名FX用VPS、お名前.com デスクトップクラウドの始め方
MT4でFXの自動売買を始めるときに、欠かせないのがVPSです。 今回は、FX用 ...
自動売買ポータルサイト、fx-onでの自動売買プログラムEAの購入方法
fx-onは、数多くの自動売買トレーダーが愛用する「自動売買ポータルサイト」です ...
低スプレッド・高レバレッジな海外FX業者 Titan FX Bladeの口座開設、入金から取引まで解説
今回は、海外FX業者の中でも最近かなり日本人に対して有名になりつつあるTitan ...
OANDA Japan FX(東京サーバー)のMT4口座がサービス改善!
嬉しい発表がありました。OANDA Japan FX(東京サーバー)のMT4口座 ...