锦标赛终点站的时间 - 页 5 1234567891011 新评论 Yedelkin 2012.09.07 14:44 #41 sergeev:耶德尔金。 请说明 "两行代码 "究竟如何回答前面提出的问题，即服务器的交易时间（报价时间）所指的时区是否使用夏令时？时间贸易服务器不幸的是，这个答案在我看来是错误的。该功能不显示服务器的 交易时间（报价时间）所指的时区是否使用夏令时。换句话说，即使服务器被引用到GMT+1时区，TimeTradeServer 函数也不能确定服务器是否会在春季切换到GMT+2。在秋天，它将相应地切换回来。在夏季，如果服务器使用 "夏季 "时间进行报价，该功能也不能回答问题。 Vladimir Gomonov 2012.09.07 23:03 #42 Yedelkin:不幸的是，这个答案在我看来是错误的。该功能不显示服务器的 交易时间（报价时间）所指的时区是否使用夏令时。换句话说，即使服务器被引用到GMT+1时区，TimeTradeServer 函数也不能确定服务器是否会在春季切换到GMT+2。在秋天，它将相应地切换回来。在夏季，如果服务器使用 "夏季 "时间来处理报价，这个函数也不能回答这个问题。你不需要服务器的时间。 如果交易是基于时间的，因为全球价格周期，那么我会严格按照格林威治时间进行交易，而不是浮躁。 服务器时间对于大脑（和程序！）来说只是一个不必要的混乱因素。 Павел Смирнов 2012.09.08 09:37 #43 亲爱的对话者们。你错过了问题的核心，这是我的引述。下面是Alpari和Metaquotes服务器报价的比较。匹配 -> 2011年5月2日 -> 轮班 -> 2011年10月31日 -> 匹配 -> 2011年11月7日 -> 轮班直到2011年5月2日，报价完全匹配（至少自2005年以来）。 然后在2011年10月31日观察到一个转变，再次转换为完全匹配的报价，直到2011年11月7日，再次出现一个小时的转变，并一直到现在。这些 "蜕变 "不能以任何方式解释!!!!如果一个经销商说EET报价的时间是与夏令时一起的，这意味着GMT+2报价的时间是从10月的最后一个星期天到3月的最后一个星期天。所有其他时间都是GMT+3（夏令时）。而且我不需要在代码中检查任何东西--它被当作一个公理!我总是知道报价是什么时候。在这种情况下，这种转变没有任何逻辑上的解释。 这是引证历史上的一个错误!也许已经讨论过了，但我错过了这一点，但重要的是，将来会如愿以偿。如果EA的普遍性对你来说很重要，也就是说，你希望你的EA无论在哪个时间段都能正确地工作，那么我认为所有的工具在MQL5中都可以使用（我自己没有测试过，但我相信开发者）。我并不关心这种普遍性。由于我的EA是根据Alpari的报价进行优化和开发的，我需要知道与Alpari的报价相比，冠军服务器的报价将如何表现，以便对EA的参数进行相应的调整!我需要一些确定性！！。我的EA的性能取决于它。Stringo回答说，服务器上的时间将是GMT+1，并改成冬季时间。这个时间被称为CET，现在是GMT+2（有夏时制的转变），2012年10月28日将转为标准时间（冬时制），时间将是CET=GMT+1。对我来说，从锦标赛的组织者那里得到我的想法的确认是很重要的！"。 这句话--"是的，会的 "就足够了。谢谢你。 Документация по MQL5: Дата и время / TimeDaylightSavings www.mql5.com Дата и время / TimeDaylightSavings - Документация по MQL5 Yedelkin 2012.09.08 09:53 #44 autoforex:亲爱的对话者们。你错过了问题的核心......没有人错过任何东西。在这个论坛上经常发生这样的情况：一个问题引发了一堆其他问题。而第一个问题的实质仍然只与作者有关。你自己可以看到。autoforex。Stringo回答说，随着冬季时间的过渡，服务器上的时间将是GMT+1。 那不是斯特林戈（在关注这个话题时要注意），但这是微不足道的。你的最后一个问题是直接向组织者提出的，所以在 "问题的核心 "讨论中，你们其他人没有什么可做的。当然，大家都希望能以正确的形式得到正确的答案，祝大家好运。我想感谢你在推动这个话题方面的顽强精神!许多人在一两个问题没有得到答复后，就干脆放弃了他们提出的话题 :) Mario 2012.09.08 21:21 #45 然而......10月28日的时间修正案是否应予规定？ Yedelkin 2012.09.08 21:26 #46 maryan.dirtyn:然而......10月28日的时间修正案是否应予规定？ 嗯，这取决于交易策略的逻辑。例如，我的策略是基于格林威治标准时间的，这就是为什么我无论如何都要纠正它的原因:)。如果我只在与CET时区有关的情况下进行交易，我就不会费心，如上所述。 Mario 2012.09.08 21:48 #47 位置在上午9点开放，晚上10点关闭。MqlDateTime time; TimeCurrent(time); if(DayClose && time.hour>=22){CLOSEALL(SY[i]); return;} 一些新闻的信号被屏蔽了。MqlDateTime time; TimeCurrent(time); if(time.mon==10 && time.day==4 && time.hour==14 && (time.min>15 && time.min<45)) News=true;逻辑是这样的。10月28日之后，我们必须增加一个小时？ Rashid Umarov 2012.09.09 00:56 #48 autoforex: 因此， 在整个锦标赛期间， 冠军服务器的报价将 比Alpari的报价移位1小时（因为他们使用EET时间=GMT+2，并且有夏令时）。我请组织者确认我的结论是否正确！！。 只在俄罗斯储蓄银行提供担保。你也可以要求提供一个估计的趋势方向，并保证在锦标赛期间不会改变。 Yedelkin 2012.09.09 06:07 #49 maryan.dirtyn:上午9点开仓，晚上10点平仓。在一些新闻中，信号被阻断。这就是逻辑。你的交易策略逻辑是与服务器时间（交易服务器时间）相联系的。由于最近宣布，对于冠军赛，将使用MetaQuotes: GMT+1时区 具有夏令时支持。我个人不会去考虑时间上的修正，也不会在 "28日之后 "增加或减少任何东西。但我必须承担三种风险。 - 事实上，报价中的时间与GMT+1时区不一致的风险。- 所引用的时间事实上不支持夏令时 的风险。- 在所引用的时间内，回到冬令时的风险将无法实施，即10月28日。当然，风险是最小的，但建议考虑这些风险。通过与格林尼治标准时间相联系，避免这些风险是可能的。MqlDateTime time; TimeGMT(time); //Плюс поправка на летнее время, если торговая деятельность завязана на таймзону с наличием летнего времени Павел Смирнов 2012.09.09 06:37 #50 Rosh: 只在俄罗斯储蓄银行提供担保。要求提供估计的趋势方向，并保证在冠军赛期间不会改变。我不知道是什么原因导致对我的问题如此 "讽刺"，但在你的回答中，有用的信息是零！我不知道。 1234567891011 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
sergeev:
请说明 "两行代码 "究竟如何回答前面提出的问题，即服务器的交易时间（报价时间）所指的时区是否使用夏令时？
时间贸易服务器
不幸的是，这个答案在我看来是错误的。该功能不显示服务器的 交易时间（报价时间）所指的时区是否使用夏令时。换句话说，即使服务器被引用到GMT+1时区，TimeTradeServer 函数也不能确定服务器是否会在春季切换到GMT+2。在秋天，它将相应地切换回来。
在夏季，如果服务器使用 "夏季 "时间进行报价，该功能也不能回答问题。
不幸的是，这个答案在我看来是错误的。该功能不显示服务器的 交易时间（报价时间）所指的时区是否使用夏令时。换句话说，即使服务器被引用到GMT+1时区，TimeTradeServer 函数也不能确定服务器是否会在春季切换到GMT+2。在秋天，它将相应地切换回来。
在夏季，如果服务器使用 "夏季 "时间来处理报价，这个函数也不能回答这个问题。
你不需要服务器的时间。
如果交易是基于时间的，因为全球价格周期，那么我会严格按照格林威治时间进行交易，而不是浮躁。
服务器时间对于大脑（和程序！）来说只是一个不必要的混乱因素。
亲爱的对话者们。
你错过了问题的核心，这是我的引述。
下面是Alpari和Metaquotes服务器报价的比较。
匹配 -> 2011年5月2日 -> 轮班 -> 2011年10月31日 -> 匹配 -> 2011年11月7日 -> 轮班
直到2011年5月2日，报价完全匹配（至少自2005年以来）。 然后在2011年10月31日观察到一个转变，再次转换为完全匹配的报价，直到2011年11月7日，再次出现一个小时的转变，并一直到现在。
这些 "蜕变 "不能以任何方式解释!!!!如果一个经销商说EET报价的时间是与夏令时一起的，这意味着GMT+2报价的时间是从10月的最后一个星期天到3月的最后一个星期天。所有其他时间都是GMT+3（夏令时）。而且我不需要在代码中检查任何东西--它被当作一个公理!我总是知道报价是什么时候。在这种情况下，这种转变没有任何逻辑上的解释。 这是引证历史上的一个错误!也许已经讨论过了，但我错过了这一点，但重要的是，将来会如愿以偿。
如果EA的普遍性对你来说很重要，也就是说，你希望你的EA无论在哪个时间段都能正确地工作，那么我认为所有的工具在MQL5中都可以使用（我自己没有测试过，但我相信开发者）。
我并不关心这种普遍性。由于我的EA是根据Alpari的报价进行优化和开发的，我需要知道与Alpari的报价相比，冠军服务器的报价将如何表现，以便对EA的参数进行相应的调整!我需要一些确定性！！。我的EA的性能取决于它。
Stringo回答说，服务器上的时间将是GMT+1，并改成冬季时间。这个时间被称为CET，现在是GMT+2（有夏时制的转变），2012年10月28日将转为标准时间（冬时制），时间将是CET=GMT+1。对我来说，从锦标赛的组织者那里得到我的想法的确认是很重要的！"。 这句话--"是的，会的 "就足够了。
谢谢你。
亲爱的对话者们。你错过了问题的核心......
没有人错过任何东西。在这个论坛上经常发生这样的情况：一个问题引发了一堆其他问题。而第一个问题的实质仍然只与作者有关。你自己可以看到。
Stringo回答说，随着冬季时间的过渡，服务器上的时间将是GMT+1。
那不是斯特林戈（在关注这个话题时要注意），但这是微不足道的。你的最后一个问题是直接向组织者提出的，所以在 "问题的核心 "讨论中，你们其他人没有什么可做的。当然，大家都希望能以正确的形式得到正确的答案，祝大家好运。
我想感谢你在推动这个话题方面的顽强精神!许多人在一两个问题没有得到答复后，就干脆放弃了他们提出的话题 :)
然而......10月28日的时间修正案是否应予规定？
然而......10月28日的时间修正案是否应予规定？
位置在上午9点开放，晚上10点关闭。
一些新闻的信号被屏蔽了。
逻辑是这样的。
10月28日之后，我们必须增加一个小时？
因此， 在整个锦标赛期间， 冠军服务器的报价将 比Alpari的报价移位1小时（因为他们使用EET时间=GMT+2，并且有夏令时）。
我请组织者确认我的结论是否正确！！。
上午9点开仓，晚上10点平仓。在一些新闻中，信号被阻断。这就是逻辑。
你的交易策略逻辑是与服务器时间（交易服务器时间）相联系的。由于最近宣布，对于冠军赛，将使用
GMT+1时区
具有夏令时支持。
我个人不会去考虑时间上的修正，也不会在 "28日之后 "增加或减少任何东西。但我必须承担三种风险。
- 事实上，报价中的时间与GMT+1时区不一致的风险。
- 所引用的时间事实上不支持夏令时 的风险。
- 在所引用的时间内，回到冬令时的风险将无法实施，即10月28日。
当然，风险是最小的，但建议考虑这些风险。通过与格林尼治标准时间相联系，避免这些风险是可能的。
只在俄罗斯储蓄银行提供担保。要求提供估计的趋势方向，并保证在冠军赛期间不会改变。
我不知道是什么原因导致对我的问题如此 "讽刺"，但在你的回答中，有用的信息是零！我不知道。