最近实盘时遇到了分钟k在上午开盘时跳过9:00:00这条k线的问题。
是否是由于早上重启服务器之后diff中没有缓存夜盘数据导致api.is_changing()函数失效？
===============================================
更新今天早上的截图，前一个是当前tick的时间戳，后一个是当前k的datetime，注意中间少了开盘时的9：00：00
api.wait_update()放在开头，用于盘后保存数据，接下来就是调用
if api.is_changing(klines.iloc[-1], “datetime”) 判断k线是否更新了
这个判断应该是第一个tick到达的时候就执行为True
lihan 更改状态以发布 2020年2月13日
是怎么跳过的，可以截图发出来看一下吗，另外你的代码中更新方式可以贴出来一下吗，有可能wait_update()没有得到及时调用？
is_changing()函数只根据最新下发的diff数据来判断，如果有新K线生成，这个新的diff中如果有is_changing()中判断的字段，那么会返回True。
lihan 发表新评论 2020年2月13日
图中那个时间是如何输出的呢？是否有在判断tick有更新之后才输出的K线？另外，是用的哪一个合约呢？
额…是判断了tick更新之后判断的….这样写实盘也不行吗？rb2005和2010，向2005对齐。 每次先判断tick是否更新，再判断k是否更新，然后把两者的时间戳打印出来
判断的是哪一个的tick，很有可能是刚开盘那时tick并没有更新，因此if下的print语句没有触发
好吧。我改成每分钟59秒算作分钟close，规避一下这个临界问题。
已更新问题