锦标赛终点站的时间 - 页 10 1...34567891011 新评论 Yedelkin 2012.09.09 16:11 #91 autoforex: 根据我的观察,它等于报价的服务器时间,即SET(对于报价服务器)。 谢谢你!当我的优化工作结束时(它必须在某个时候结束),我将尝试检查那里到底发生了什么。 [删除] 2012.09.09 17:47 #92 autoforex: 它将返回当前蜡烛的时间 = CurrentTime()。这很容易检查。是的,我正在处理这个问题。一年前,我写了几个函数,通过三个分水岭(可以减少到两个)确定任何蜡烛图的当前 GMT时间。重要的输入是:服务器时区(表示为与格林尼治标准时间的偏差)和冬/夏过渡类型(无/欧洲/美国)。只是想说,这显然不是两根弦,也远不是普遍的选择。PS开发人员甚至懒得通知那些我必须自己指定的 "输入",而计算重复和重写大量的代码。关键是这一点。 Документация по MQL5: Дата и время / TimeCurrent www.mql5.com Дата и время / TimeCurrent - Документация по MQL5 [删除] 2012.09.09 17:51 #93 Yedelkin:你的结论与你自己的观察相矛盾 :)首先,你观察到TimeCurrent()==22.00==TimeGMT(),但不想承认测试器中的TimeCurrent()==TimeGMT()。也就是说,你不想承认服务器时间与测试器中的GMT时间一致。是的,这就是整个 "不测 "的原因。如果我们谈论的是测试者,那么显然 "有人相信 "所有的个人电脑都在按服务器时间运行,而且所有的服务器都在格林尼治标准时间区。在这种情况下,冬季/夏季的过渡,不可能有一个。耶德尔金。支持你的立场的出色结论 :)- 测试员的错:)错不在测试者,而在于那些 "发明 "了将所有时间(绝对的一切)与报价时间绑定的人。在这种情况下,无论是在测试者还是在交易环境中,都没有关于交易服务器所在区域和时间是否变化的信息。似乎很难再增加两个参数,例如在AccountInfoInteger 中增加两个参数,并在测试器中改变TimeGMT 的行为(以便根据服务器区来纠正结果)。耶德尔金。 谢谢!当我的优化工作结束时(它必须在某个时候结束),我将尝试检查那里到底发生了什么。发生的事情很简单,本地时间和格林尼治标准时间与服务器时间 "相等",而TimeGMTOffset 则假装冬夏时间转换从未存在。所以至少 应该改变测试仪中 两个函数TimeGMTOffset 和TimeGMT 的行为。 IMHO Yedelkin 2012.09.09 18:13 #94 Interesting: 如果我们谈论的是测试者,那么显然 "有人认为 "所有的电脑都是按服务器时间运行的,而且所有的服务器都在格林尼治标准时间区。 关于测试器中的历史时间的话题很好!我个人天真地以为,如果服务器时间被设置为GMT+0,报价将只以GMT+0的形式存储。现在,我们将不得不检查这一点,并在必要时根据测试者的实际情况进行调整。 [删除] 2012.09.09 18:21 #95 Yedelkin: 关于测试器中的历史时间的话题很好!就个人而言,我天真地以为,如果测试中的服务器时间是GMT+0,那么引号将以GMT+0的格式存储。现在,我们将不得不检查这一点,并在必要时根据测试者的实际情况进行调整。我已经做了一年了,在我的测试器中没有它,我就不能做任何事情。我以前没有碰过测试器中的"当地时间",但我想我必须这样做。在我看来,对于在测试器中的正常工作,你应该在参数中指定区域和冬季/夏季过渡的可能性(对于 "当地 "时间),而服务器设置则来自于贸易环境。即,理想情况下,根据那些在交易环境中的数据和时间报价来确定GMT,然后在GMT的基础上和测试器的参数来确定当地时间。但开发商不会这样做,因为只有两三个交易商 "需要 "它。 Yedelkin 2012.09.09 18:23 #96 Interesting: 那里发生的事情很简单,当地时间和GMT被 "等同于 "服务器时间,而TimeGMTOffset 则假装冬/夏转换从未存在过。我知道这个功能。我以为它就在那里,所以到目前为止还算满意。但是,如果将测试器中的格林尼治时间等同于服务器时间(用你的术语来说)会导致某种时间跳跃,我将不得不完善该代码。 Yedelkin 2012.09.09 18:27 #97 Interesting: .. 因为在所有交易者中,有两三个人 "需要 "它。 你是否也总是提前准备好那句不朽的名言?:):):) [删除] 2012.09.09 18:41 #98 Yedelkin: 你是否也总是提前准备好那句不朽的名言?:):):) 有些事情你宁愿自己去做(即使是使用拐杖的混乱),而不是等待 "大自然的恩赐"...... Anatoli Kazharski 2012.09.10 00:55 #99 Interesting: 有些事情自己去实施(即使是使用拐杖的混乱)比等待 "自然的恩典 "更好...... 你是否就这个特定问题写信给服务台?有答案吗?如果有这样的问题,它涉及的不是两三个人,而是每个使用测试器的人。))) [删除] 2012.09.10 00:57 #100 tol64: 你是否就这个特定问题写信给服务台?是否已经有了答案?如果有这样的问题,这不是两三个人的问题,而是每个使用测试器的人的问题。))) 我写了,但显然当时的星星在错误的星座。 1...34567891011 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
它将返回当前蜡烛的时间 = CurrentTime()。这很容易检查。
是的,我正在处理这个问题。一年前,我写了几个函数,通过三个分水岭(可以减少到两个)确定任何蜡烛图的当前 GMT时间。
重要的输入是:服务器时区(表示为与格林尼治标准时间的偏差)和冬/夏过渡类型(无/欧洲/美国)。
只是想说,这显然不是两根弦,也远不是普遍的选择。
PS
开发人员甚至懒得通知那些我必须自己指定的 "输入",而计算重复和重写大量的代码。
关键是这一点。
你的结论与你自己的观察相矛盾 :)首先,你观察到TimeCurrent()==22.00==TimeGMT(),但不想承认测试器中的TimeCurrent()==TimeGMT()。也就是说,你不想承认服务器时间与测试器中的GMT时间一致。
是的,这就是整个 "不测 "的原因。
如果我们谈论的是测试者,那么显然 "有人相信 "所有的个人电脑都在按服务器时间运行,而且所有的服务器都在格林尼治标准时间区。
在这种情况下,冬季/夏季的过渡,不可能有一个。
支持你的立场的出色结论 :)- 测试员的错:)
错不在测试者,而在于那些 "发明 "了将所有时间(绝对的一切)与报价时间绑定的人。
在这种情况下,无论是在测试者还是在交易环境中,都没有关于交易服务器所在区域和时间是否变化的信息。
似乎很难再增加两个参数,例如在AccountInfoInteger 中增加两个参数,并在测试器中改变TimeGMT 的行为(以便根据服务器区来纠正结果)。
谢谢!当我的优化工作结束时(它必须在某个时候结束),我将尝试检查那里到底发生了什么。
发生的事情很简单,本地时间和格林尼治标准时间与服务器时间 "相等",而TimeGMTOffset 则假装冬夏时间转换从未存在。
所以至少 应该改变测试仪中 两个函数TimeGMTOffset 和TimeGMT 的行为。 IMHO
关于测试器中的历史时间的话题很好!我个人天真地以为,如果服务器时间被设置为GMT+0,报价将只以GMT+0的形式存储。现在,我们将不得不检查这一点,并在必要时根据测试者的实际情况进行调整。
关于测试器中的历史时间的话题很好!就个人而言,我天真地以为,如果测试中的服务器时间是GMT+0,那么引号将以GMT+0的格式存储。现在,我们将不得不检查这一点,并在必要时根据测试者的实际情况进行调整。
我已经做了一年了,在我的测试器中没有它,我就不能做任何事情。
我以前没有碰过测试器中的"当地时间",但我想我必须这样做。
在我看来,对于在测试器中的正常工作,你应该在参数中指定区域和冬季/夏季过渡的可能性(对于 "当地 "时间),而服务器设置则来自于贸易环境。
即,理想情况下,根据那些在交易环境中的数据和时间报价来确定GMT,然后在GMT的基础上和测试器的参数来确定当地时间。
但开发商不会这样做,因为只有两三个交易商 "需要 "它。
我知道这个功能。我以为它就在那里,所以到目前为止还算满意。但是,如果将测试器中的格林尼治时间等同于服务器时间(用你的术语来说)会导致某种时间跳跃,我将不得不完善该代码。
你是否也总是提前准备好那句不朽的名言?:):):)
有些事情自己去实施(即使是使用拐杖的混乱)比等待 "自然的恩典 "更好......
你是否就这个特定问题写信给服务台?是否已经有了答案?如果有这样的问题,这不是两三个人的问题,而是每个使用测试器的人的问题。)))