伦敦突围赛 - 页 2

新评论
 

是的，都是因为IMO的一个令人费解的设计决定:) 因此，在一年中，服务器时间甚至可能不对应于任何已知的世界时钟。

我有一个方法可以准确地确定GMT时间，特别是在回溯测试期间。这个方法似乎对以下的经纪商有效

  • 在他们的历史数据中改变了TZ（Alpari）。
  • 或者像Thirteen指出的那样，对他们的时区使用非标准的DST（FXCM）。

但我仍然觉得这个方法有点儿黑。

它涉及从其他来源（dukascopy）下载基于GMT的报价，并比较每日高点的小时数。对于回溯测试来说，效果不错，但目前我正在手动下载小时数据，并过滤高点（使用perl脚本）。

一旦我可以从至少两个来源自动获得GMT H1的报价，那么我就可以放心地使用这种方法来达到我的目的。

 
SDC:

怎样才能使MT4更适合做这个？ 我不知道你是怎么想的，但我肯定不会喜欢创建一个区域性的历史GMT偏移计算器的任务。你能想象吗？如果我做了，我会把它放到市场上，你们最好都有一个大的支票簿；)

一个历史性的GMT计算器本身并不特别难（Windows操作系统已经包含了所有你需要的数据），但并不是首要问题。问题是，你可以确定经纪人时间和格林尼治标准时间之间的当前偏移量，但你不知道它是否/何时改变。使用上面的例子，你可以看到经纪人目前在GMT+3（假设本地电脑时钟是准确的......），但你不知道经纪人上周是在GMT+2。

很有可能是MT4客户终端根本没有这个信息。

如果它有，那么MT4可以提供裸数据，你可以自己处理，或者提供一个功能，让你说 "把过去的任何经纪商日期转换成GMT"。一旦你有了这个功能，你可以使用查询表（或Windows API）将过去的GMT时间转换为另一个时区，如伦敦。然而，最好是MT4也能为您做到这一点，例如，一对函数，如以下。

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone)。

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone)。

 
ydrol:

是的，都是因为IMO的一个令人费解的设计决定:)

(我假设不固定在UTC的原因是，经纪人可以在EET运行，每周提供五个D1蜡烛，避免第六个小蜡烛，导致系统低估的东西，如使用GMTZ的经纪人的D1 ATR)。
 
gchrmt4:
(我假设不固定在UTC的原因是，经纪人可以在EET运行，每周提供五个D1蜡烛，避免第六个小蜡烛导致系统低估的东西，如使用GMTZ的经纪人的D1 ATR。)


我本来想把所有这些东西放在客户端，但这使客户端在不同的地方变得更加复杂:)但至少所有的变量都是已知的。
 

另一种方法，根据这个页面 ，只有62个MT4经纪商？因此，为每个经纪商和他们的时间定义（无论它是基于真正的时区还是像FXCM那样的组合）建立一个查询表，并纳入历史变化（像Alpari那样），并不是太难。

这可能是最稳健的方法，只是需要在每次经纪商决定想让其客户更困惑时进行调整 :)

 

gchrmt4:

[1] 你的服务器时间GMT+3可能对应于EEST，因为EEST是GMT+3，但根据维基百科和worldclock.com，现在还没有哪里应该是EEST。这一变化应该在3月30日前发生。塞浦路斯、希腊、以色列等地的当前时间是GMT+2。

[2] 因此，你所遇到的可能是一个经纪商以GMT+2运行其服务器，但在美国日期而非欧洲日期改变为夏令时。

[3] 这与EET/EEST不一样。(就能够编写自动调整时间和日期的代码而言，它甚至更难预测，而不必要求用户输入关于经纪人使用何种时间设置的信息)。

  1. 正确。
  2. 正确的。
  3. EET是GMT+2，但GMT+2不仅是EET。 另外，EEST是GMT+3，但GMT+3不仅仅是EEST。 我把我的经纪人的时区描述为EET/EEST，只是想推断在标准时间时是GMT+2，在夏令时时是GMT+3，特别是由于这个主题讨论的是伦敦的突破。 如果我的描述导致了一些混淆，我深表歉意。）

因此，如果经纪商最近从GMT+2变为GMT+3，而不是即将从GMT+3变为GMT+4，这意味着如果你试图把它应用到上周美国时钟变化之前的条形图上，经纪商时间和GMT之间的当前偏移是错误的。本周，经纪人的条形图比伦敦时间早3小时。上周他们是提前2小时。(如果你把目前的3小时偏移量用来计算上周某天伦敦时间上午8点的价格，你会得到错误的答案。

经纪人一般不会经常改变其服务器的时区，除非是为了调整夏令时。 对于夏令时的调整，我可以使用任何日期/时间（从1987年（美国）和1996年（欧盟）到2020年及以后），并计算出美国和欧盟的夏令时开始日期和夏令时结束日期。 一旦你有了这段代码，你所要做的就是调整当前对格林尼治标准时间的偏移量，以适应你所看的日光节约时间。

使用TimeGMT()，这是在Build 600+中的新功能，你可以计算出你的经纪人对格林威治时间的当前 偏移量。 但是，你不能（据我所知）从过去的时间确定一个经纪人的时区。 例如，我有一个经纪人把它的服务器的时区从标准时间的GMT改为标准时间的GMT+2。 我通过硬编码来处理这个问题，因为所有的历史数据都是GMT，而不是GMT+2（而且我不想修改历史来反映GMT+2）。 在这方面，我相信你和我都同意。 只要经纪人不随便改变时区（除了为夏令时而调整），你应该能够计算出与格林威治标准时间的偏移量，并为夏令时调整该偏移量。

我想说的是，仅从MT4本身获得的信息--经纪人时间和格林威治时间之间的当前偏移量--在实践中不足以做诸如 "计算出上周三伦敦的开盘价 "的事情。

我相信我不同意你的观点。 只要经纪商不改变时区，除了调整夏令时， 你可以确定与格林威治标准时间的偏移，无论是当前时间 还是历史时间。 如果上周在标准时间，经纪人是GMT+2，伦敦是GMT，那么伦敦时间上午8点将是服务器时间上午10点。 下个月，在夏令时，当经纪人是GMT+3而伦敦是GMT+1时，伦敦时间上午8点将对应于服务器时间上午10点。 今天，当经纪人在夏令时，伦敦在标准时间，经纪人是GMT+3，伦敦是GMT，所以伦敦时间上午8点将是服务器时间11点。

如果经纪人是GMT-5（美国东部时间），伦敦是GMT，那么伦敦时间上午8点就是服务器时间3点。

 
gchrmt4:

历史上的GMT计算器本身并不特别难（Windows操作系统已经包含了你需要的所有数据），但并不是主要问题。问题是你可以确定经纪人时间和格林威治标准时间之间的当前偏移量，但你不知道它是否/何时改变。使用上面的例子，你可以看到经纪人目前在GMT+3（假设本地电脑时钟是准确的......），但你不知道经纪人上周是在GMT+2。

很有可能是MT4客户终端根本没有这个信息。

如果它有，那么MT4可以提供裸数据，你可以自己处理，或者提供一个功能，让你说 "把过去的任何经纪商日期转换成GMT"。一旦你有了这个功能，你可以使用查询表（或Windows API）将过去的GMT时间转换为另一个时区，如伦敦。然而，最好是MT4也能为您做到这一点，例如，一对函数，如以下。

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone)。

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone)。


是的，如果没有夏令时，这并不困难，但有lol......这将是一个噩梦的代码。历史上的反常现象将无处不在。有些地区改变了他们使用的时区，有些地区尝试完全不使用夏令时，然后又恢复到夏令时，有些地区在某些地方尊重夏令时，但在其他地方不尊重，会有很多异常情况需要考虑，世界各地都是如此......
 
ydrol:

另一种方法，根据这个页面 ，只有62个MT4经纪商？因此，为每个经纪商和他们的时间定义（无论它是基于真正的时区还是像FXCM那样的组合）建立一个查询表，并纳入历史变化（像Alpari那样），也不是太难。

62是一个不足的估计，而且较大的经纪商的服务器设置在不同的时区。
 

Thirteen:

如果，上周在标准时间内，经纪人是GMT+2，伦敦是GMT。

仅仅使用MT4提供的信息，你如何知道经纪商上周是GMT+2的？
 

按照常理，MT4服务器应该一直使用GMT，但你知道他们不会这么做。

123
新评论