Dukascopyのヒストリカルデータは時間がズレている




Dukascopyのヒストリカルデータ

 
いくつかのEAのバックテストをしていた時に、ヒストリカルデータでEAによる結果の違いが大きいということに気が付き、調べておこうと思ったのがきっかけです。Dukascopyは比較的データの抜けがないのですがそのままでは使いずらいようです。
 

 

UTC+0

 
こちらの手順でデータをダウンロードしたのですが、ヒストリカルデータの取得方法
デフォルトではUTC+0(≒ GMT+0)の時間になっています。

MT4はGMT+2/+3なので時間のずれが生じます。

2020/1/24 金曜日の21:59

次の足が
2020/1/26 日曜日 22:00 となっています

その後は 2020/1/26 23:59

次の足が
2020/1/27 月曜日 0:00
金曜日の2時間が日曜日にずれ込んでいる

日足で見ると26日の日曜日ができて1足多くなってしまっています

 

EET(UTC+2)による調整

 
2時間のズレは JForex Platform の設定で、
「プラットフォームの時間」を EET(UTC+2時間) にすることで多少調整できます。(EETは東ヨーロッパ時間)
 

 
それとダウンロード形式はCSVでないとHSTでは反映されません。また、CSVデータの取り込みはそこそこ時間がかかります。
 

このCSVに余計なヘッダーがあるので取り込めない場合があるので
xxx.csv ファイルのヘッダー部分の「Time…」の1行を削除します。


 
また、csvファイルは大きすぎてExcelでは開けないことがあります。そんな時はVS Codeであればパワフルなので大丈夫です
 

MQL4のコーディングでMetaEditorの代わりに使えるものがないかと探していましたら、Visual Studio Codeがありま...
 
因みに、問題の箇所を見て見ると

2020/1/24 23:59:00 まで伸びて土日が無くなり 1/27 00:00:00 から始まっています。

チャートでみても調整されています。

 

EETの問題点

 
実はこれですべて解決ではありません
EETを使ったのもありますが夏時間調整が多少おかしなことになっています。
結論から言うと

  • 3月 最終日曜日の前の週の金曜日が1時間足りない
    3/29(金曜日)が22:59で終わっている
     
  • 10月 最終日曜日に2時間分データが余計にある
    10/27(日曜日)に22:00から23:00のデータが入っている

これは夏時間調整からきていると思われます。

あくまでMT4はNewYorkのPM5時がその日の終わりという設定なので
NewYorkの夏時間はヨーロッパの夏時間とは1~2週間ずれます。
 

MT4の時間がGMTそのものでなく+2時間や+3時間(夏時間)というのはどう言うことでしょうか? NewYorkの17:00(クロ...
 
実は私のEAの幾つかは金曜の夜には手仕舞うので、それほどこれが問題ではありません。
ただどうなっているというのを理解しておくのは必要なのと、当然スウィング系のEAの場合は問題になります。

 

補正スクリプト

 
このUTCの時間のずれを補正してくれるスクリプトがあります
UTC+0のヒストリカルデータを、UTC+2/+3や日本時間(UTC+9)にするVBスクリプト

テキストをコピペし、ファイル拡張子.vbsとしてHSTファイルにドロップするとworkフォルダに変換ファイルを出力してくれます。


シェアする

  • このエントリーをはてなブックマークに追加

フォローする