开发人员。MT5终端的时间格式 - 页 4

[hrenfx]

stringo:

GetTickCount?整个事情？别傻了。

你的交易需求并不代表GetTickCount的有限能力

GetTickCount的有限可能性完全解决了在元组内测量tick rate是否有用的问题。

这里甚至不需要争论，任何人都可以很快解决这个问题。

至于一般的毫秒和我的需要，我已经 或多或少地证明了我对MT5中毫秒无用的看法。

[Slava]

Swan:

所有的计算都是基于最后10个（或多少个）刻度...

如果是一分钟的tick_volume，那就有点不同了）周期长了一个数量级。

如果你以分钟为单位，用60,000毫秒除以tick_volume的大小，那么在每一个被检查的分钟内收到的ticks的比率不是精确到毫秒吗？

如果我们把当前本地计算机的时间 用毫秒表示（使用WinAPI工具），用这些毫秒除以当前累积的tick_volume，不就可以得到当前的tick到达率吗？

[Slava]

hrenfx:

在一个元组内测量tick rate的有用性问题被GetTickCount的有限能力完全解决了。

甚至没有必要争论，任何人都可以很快解决这个问题。

至于一般的毫秒和我的需要，我已经 或多或少地证明了我对MT5中毫秒无用的看法。

没有人阻止你用毫秒获取当前时间。剩下的就是技术问题了。

[Aleksey Lebedev]

hrenfx:

但GetTickCount完全解决了这个简单的问题。毫秒与此毫无关系。

这是个好主意。我应该试试）。

但如果有了几毫秒的勾选时间，那就更容易了。

[Slava]

我甚至为fours写了一个脚本，以毫秒为单位获取当前时间。在四个论坛上查一查。

[[删除]]

Swan:
这里不允许有广告 :)

当一个仓库在排水而又没有解释时，人的思想就会从极端走向极端，寻找原因，却忘记了照镜子。

[hrenfx]

stringo:
没有人阻止你获得以毫秒为单位的当前时间。剩下的就是技术问题了。

你一定没有仔细阅读。

P.P.S. 没有人阻止你用毫秒来收集元中的ticks（通过GetTickCount的模拟）。这很简单。问题是，这是否有必要。

GetTickCount的好处是，它不需要MQL中的WinAPI。但其优势更强，因为本地时间不一定与交易服务器的时间同步。而关于tick到达时间的数据必须在交易服务器时间收到。这就是为什么用GetTickCount来模拟毫秒。因此，准确性比考虑两个时间之间不断浮动的差异要高。

你看，这不是理论上的推理，而是实际交易。

[---]

hrenfx:
而关于tick的到达时间的数据必须在交易服务器的时间内收到。因此，毫秒是通过GetTickCount来模拟的。因此，精确度比考虑到不断浮动的两个时间的去同步化要好。

+正确。

在终端侧测量时间意味着在发送数据时有延迟。

而有一个来自服务器的保存时间正是你所需要的。

斯坦尼斯拉夫。 但你已经在系统中拥有了它的订单。只要把它交给终端，让交易员拿着它就可以了。

对于蜱虫，这个问题在服务器层面没有得到解决，这就是为什么我甚至不会提到它。

[[删除]]

papaklass:

看，当抽搐向你袭来时，它表明以下事情之一已经发生。

1.如果第一级出价发生了变化（Bid_1）。

2.如果Bid_1没有变化，但这个价格水平的交易量发生了变化（增加/减少）。

如果Bid_1没有变化，而Bid_2或Bid_2价格水平的成交量发生了变化。

等。

现在，每个价格水平的买入价、卖出价和成交量也在一起。 你能想象有多少不同的数据吗？而这一切都被装进了1c。

一秒钟内可能有多达几十次这样的抽动。如何对它们进行分类？ 1s的时间步长是一个非常粗糙的分类，我们需要一个精细的时间步长--毫秒。一般来说，它是否清楚？

，好吧，那又怎样......例如在服务器上的延迟和所有的比特和问话在未来仍然会出现，不管他们是多少。

这对交易有什么真正的帮助...？我还不明白，除了衡量波动性。

顺便问一下，你确定如果MC增加了m.s.，所有具有毫秒速率的ticks都会从最初的来源到达你的显示器（最终的视觉点）吗？

[Andriy Voitenko]

我读过这篇文章，了解到毫秒只是为了好玩而需要。要能够测量100米跑的价格，精确到毫秒。

sergeev

只要把它交给终端，这样交易员就可以拿走它。

为了给他们，数据时间 类型必须变成10个字节，MqlDateTime结构必须变得更胖。

等到了MQL6，毫秒计时器、勾选历史和其他很多好东西都会出现在那里。但我不认为现在添加它有什么意义。IMHO。