xiaohe wrote:

jingsiaosing wrote:

米筐的分钟bar切割规则是不是变更过？我看之前load下来的数据是向前归结的，最后一个bar是14:59, 和vnpy的BarGenerator的逻辑是一致的，最近重新拉的数据是向后归结的，最后一个bar是15:00 虽然对回测和交易影响都不大，但是数据一致性不能保持的话不敢用啊
请问你指的之前load下来的数据是通过米筐直接拉的，还是通过vnpy下载的？通过米筐直接下载和通过vnpy使用rqdata下载datetime是不一样的。米筐是15:00为最后一根，vnpy是14:59为最后一根。

那破案了 之前确实是通过vnpy下载下来的数据 谢谢回复:)

米筐的分钟bar切割规则是不是变更过？我看之前load下来的数据是向前归结的，最后一个bar是14:59, 和vnpy的BarGenerator的逻辑是一致的，最近重新拉的数据是向后归结的，最后一个bar是15:00 虽然对回测和交易影响都不大，但是数据一致性不能保持的话不敢用啊

嗯是的 我看了BarGenerator的源代码还以为自己理解错了，因为如果按照自带的BarGenerator来做行情记录，就会和Rqdata拉下来的数据对不上了，比Rqdata多了一根bar。集合竞价的tick是否要单独作为一个bar还是看交易需求的，不过一般的数据服务商是把它和后面一分钟的tick合并在一起算的，这样在合并N分钟或者小时K的时候，避免了除不尽的尴尬。
hxxjava wrote:

jingsiaosing wrote:

一个类似的问题：开盘第一个tick的时间戳是20:59:00，第二个tick的时间戳是21:00:00, 他俩的minute不一样，所以在收到第二个tick的时候就会推送bar，bar的时间戳是20:59:00,是这样吗？

这也是也个问题，实盘中每个合约都会有集合竞价时段，这时候采用自带的BarGenerator来合成1分钟bar就会有问题，因为20:59:00的那个tick既不属于上一交易日的1分钟bar（15:59）的，也不属于21:00的那一个1分钟bar，当然就只能够孤独地自成一个1bar啦！由此带来的问题是21:00的那一个1分钟bar的开盘价和成交量（这个成交量可能是很大）都可能是错了。
当然由此导致的5分钟、10分钟、15分钟、30分钟乃至1日的bar都可能是有问题的，因为它们都是1分钟bar合成的。
解决方法：

• 从合约信息中提前交易时间段信息入手，通常某个交易日的第一个交易时间段前1分钟收到的tick应该归入该交易日的第一个1分钟bar，
• 如国内期货的为前一交易日的21:00的前1分钟收到的tick应该归入21:00的那一个1分钟bar，
• 股指期货的为当前交易日的9:30的前1分钟收到的tick应该归入9:30的那一个1分钟bar。
• 在正确处理了交易日首个1分钟bar合成的基础上，其他的n分钟bar的合成才可能是正确的。

一个类似的问题：开盘第一个tick的时间戳是20:59:00，第二个tick的时间戳是21:00:00, 他俩的minute不一样，所以在收到第二个tick的时候就会推送bar，bar的时间戳是20:59:00,是这样吗？