服务台：懒惰、自闭还是不愿意承认错误？用非本土的蜡烛来补充图表的内容。
这就是你一个月前提出的问题吗？https://www.mql5.com/ru/forum/1111/page878#comment_344461
FiftyStars。
...故事就是这样的。我们没有深刻的分钟历史。为了您的方便，更深层次的历史是由每日条形图表示的。
如果你不方便，请手动 限制 该历史记录的使用。
当时就已经知道了答案的要点（https://www.mql5.com/ru/forum/1111/page878#comment_344518）。
但我担心它（答案）会是这样的："程序员自己可以计算出边界日期，并限制所要求的历史深度。
我与服务台联系，提出了一个问题，即当低层TF上没有历史记录时，将高层TF蜡烛附加到低层TF图表上。这意味着，当我们在M1图表中走到历史的起点时，我们看到的蜡烛不是来自M1，而是来自D1，甚至是来自W1。由于这一加入，SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x)函数返回的不是M1历史结束的日期，而是时间框架外第一个条形的日期，也就是说，指定的时间框架不会影响结果。
...
SERIES_BARS_COUNT 返回属于某个符号和时间框架的蜡烛（柱）的数量。
SERIES_FIRSTDATE返回属于某个符号和时间框架的第一个蜡烛（柱）的开盘日期。
更多信息
...
这些功能都能正常工作。
你所看到的是你以前的历史质量要求的结果。
历史就是这样的。我们没有深刻的分钟历史。为了您的方便，更深层次的历史是由每日条形图表示的。
如果你不方便，请手动限制该历史记录的使用。
这是一个坦率的借口，程序员不能预见所有的历史咬合的选项，所以他不能规定搜索TF的第一个日期的功能。今天他们是这样的，明天他们会有新的曲折，在MQ不知情的情况下，比如说交易会把一些事情搞砸。
而我们为什么需要它，因为有一个标准的功能，但它提供前天的天气，已经是一个彻头彻尾的错误。
这里是程序员问题的关键所在。
我们需要搜索标准的变体，根据这些变体，该条可以被认为是所选TF的第一条，而之前的所有条--从旧TF中增加的条。可能会有小节上的空白，如漏掉的小节（这是MQ选择的小节记录格式的直接后果）或小节上的空白，如周末/假日。而在这样一个喧嚣的标志中，不清楚如何确定这个酒吧是正确的。
对MQ来说，问题的本质是什么：（如果我们的意思是他们要解决这个问题的话）
当历史被缝制到一个文件加密数据的缝制点（没有很多，最多21个由TF的数量，在实践中，有2-3），问题就解决了。接下来，写一个函数来读取这些受保护的信息，并通过请求将其输出给用户。
谢谢你，不要为商人决定。
是什么新鲜的脑袋在周五之后做出这样的举动--在M1 时间框架中插入旧的条形图 ？
谁甚至给了你这样的权利--推翻多年来的既定原则？
如果你不适应，请手动限制这个故事的使用。
谢谢你，不要为商人决定。
是什么新鲜的脑袋在周五之后做出这样的举动--在M1 时间框架中插入高级条 ？
谁给你的权利来推翻多年来的既定原则？
亚历克斯，不要夸大其词，在他们决定从M1开始计算所有的TF后，需要TF胶合剂来正确计算所有其他的TF。
如果你还记得，它让我们计算出多达21个TFs（包括非标准的TFs）。
关于这一点，没有人告诉它，而且不止一次。我们不会回到单独存储每个TF的旧系统，你明白的。
但是，实现起来给程序员增加了更多的麻烦，这是一个事实。而且这个问题很容易解决，但是没有，我们更知道你需要什么 :(
所以这就是我的疑问。
Если вам это не удобно - ограничивайте использование этой истории вручную.
亚历克斯不要夸大其词，在决定从M1开始计算所有的TF后，需要进行TF胶合，以正确计算所有其他的TF。
解决方法是在历史记录中设置一个标识符，在读取时，如果该条数据不属于M1，则不会在M1中输出，不属于M5，则不会在M5中输出。或者是的......我们应该在FirstDate中写出当前时期的条形图与更高时期的条形图的连接日期，用户将有可能知道从哪个日期开始处理，以避免捕捉较早的条形图。
- www.mql5.com
我同意，这是个垃圾。
而如果有句号分隔符，则是一种美。
而且你必须在代码中扭动它（（。
我与服务台联系，提出了一个问题，即在较低的TF上没有历史记录时，将较高的蜡烛附加到低的TF图表上。也就是说，当我们在M1图表中走到历史的起点时，我们看到的蜡烛不是来自M1，而是来自D1，甚至是来自W1。由于这一加入，SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x)函数返回的不是M1历史结束的日期，而是时间框架外第一个条形的日期，也就是说，指定的时间框架不会影响结果。当询问时，我得到的借口是，这对用户来说很方便，每个符号的每个时间框架的截止日期都应该手动设置。对不起，这个函数不是应该由函数SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x)来执行吗？如果结果相同，SERIES_FIRSTDATE与指定的TF M1中 的SERIES_FIRSTDATE 有何不同？
这是什么乱七八糟的东西？是谁，为什么会有这样的便利？没有人愿意在M1图表上看到W1蜡烛。好吧，除了受虐狂......。
我得出以下结论：要么是开发者有自闭症（他们生活在自己的世界里，上面和下面是常态，或者说不是常态，但工作是5+），要么是他们太懒了，无法解决，或者是 "我们怎么从来没有错，我们都很好 "的原则。那么，也有一些变种：他们开玩笑，他们不知道如何解决。
下面是截图，你可以清楚地看到不同TFs的历史连接线。
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
询问1。
终端的版本和比特率
Build 712 x86
问题描述。
小时间段的历史数据由大时间段的历史数据来延续。这意味着，例如，欧元兑美元在M1上的历史结束于~1999年1月4日，而在M1图表的左侧是1999年1月4日之前的D1图表。
在所附的屏幕截图中，可以看到它。正因为如此，带有SERIES_FIRSTDATE参数的SeriesInfoInteger函数工作不正常。该函数返回整个历史的第一个日期（包括时间段D1、W1和MN1），而不是符号-周期的第一个日期。
行动的顺序
滚动图表到历史的起点
获得的结果
延续图表中较大时间段的历史数据。
预期的结果
在给定的时间框架上的历史数据结束时对图表的限制。
其他信息
要求2。
终端版本和比特率
build 712 x86
问题的描述
文件中的描述。
series_bars_count。
目前每个符号-周期的条数
长
系列_第一个日期
当前符号周期的第一个日期
日期时间
由于低层TF的历史的加入，在低层TF上没有特定时期的历史，而在大层TF上有同一时期的历史的情况下，例如M1的图表显示了来自D1图表的蜡烛。
是否正在准备解决这一问题的方案？除了手动限制外，目前有什么办法解决这个问题吗？
行动的顺序
使用这些功能
获得的结果
SERIES_BARS_COUNT在低时间段（最高到D1）返回属于该符号和时间段的蜡烛（条）数，加上最近的更大时间段的蜡烛数，对于这些历史数据是可用的。
SERIES_FIRSTDATE在低时间段（最高到D1）返回历史上第一个蜡烛（柱）的开盘日期。
预期的结果
SERIES_BARS_COUNT 返回属于一个特定符号和时间框架的蜡烛（柱）的数量。
SERIES_FIRSTDATE返回第一个蜡烛（柱）的开盘日期，它属于一个指定的符号和时间框架。
更多信息
...
这些功能都能正常工作。
你所看到的是你以前的历史质量要求的结果。
历史就是这样的。我们没有深刻的分钟历史。为了您的方便，更深层次的历史是由每日条形图表示的。
如果你不方便，请手动限制该历史记录的使用。