数据公开了但还没进你的库，回测该按哪个时间放行

研究公共信息边界时按公开时间放行；重放某一系统实际运行时，还必须等该版本入库。两者回答不同问题，不能统一用一个“日期”代替。本篇构造两源四版本、四个决策截点，同时给出公共快照、实际系统快照及额外延迟情景，展示相同公开资料在不同管道中未必同时可用。

两源、版本与观察期怎样定义

A与B都是构造数据源，描述同一2026年9月观察期，数值为无量纲教学量，不代表收入或真实宏观指标。时间原点为2026年10月20日09:00Z，表中release、ingest、decision均为距原点分钟数。版本号只在各源内部比较，不能用A的版本二覆盖B的版本一。

完整构造输入如下。时间和状态按本篇约定解释，JSON中的null代表未知而非零：

{
  "columns": [
    "源",
    "版本",
    "值",
    "release分钟",
    "ingest分钟"
  ],
  "decisions": [
    3,
    6,
    8,
    10
  ],
  "observation": "构造2026-09期",
  "origin": "2026-10-20T09:00:00+00:00",
  "rows": [
    [
      "A",
      1,
      100,
      0,
      4
    ],
    [
      "B",
      1,
      200,
      1,
      2
    ],
    [
      "A",
      2,
      110,
      5,
      9
    ],
    [
      "B",
      2,
      190,
      7,
      8
    ]
  ]
}

A第一版值一百，在原点公开、四分钟入库；B第一版二百，一分钟公开、两分钟入库。A第二版一百一十，五分钟公开、九分钟入库；B第二版一百九十，七分钟公开、八分钟入库。每行都有原始观察期、来源、版本、公开时刻与入库时刻，四种坐标不能互换。

决策截点为三、六、八、十分钟。公开边界要求release不晚于截点；实际系统还要求ingest不晚于截点。满足条件后，在每源各自的候选里选择最近公开版本，本例同一源无并列公开时间。未取得某源时两源和为空，不把缺源贡献默认为零。

四维筛选怎样逐候选展开

ingest	release	值	公开可用	决策分钟	源	版本	系统可用
4	0	100	是	3	A	1	否
2	1	200	是	3	B	1	是
9	5	110	否	3	A	2	否
8	7	190	否	3	B	2	否
4	0	100	是	6	A	1	是
2	1	200	是	6	B	1	是
9	5	110	是	6	A	2	否
8	7	190	否	6	B	2	否
4	0	100	是	8	A	1	是
2	1	200	是	8	B	1	是
9	5	110	是	8	A	2	否
8	7	190	是	8	B	2	是
4	0	100	是	10	A	1	是
2	1	200	是	10	B	1	是
9	5	110	是	10	A	2	是
8	7	190	是	10	B	2	是

三分钟时A第一版已经公开但未入库，B第一版两者都满足。六分钟时A第二版公开却未入库，系统仍只能用A第一版；八分钟时B第二版刚入库，A第二版仍待九分钟。这个候选级真值表比只给最终值更容易审计，因为每次差异都能追溯到一个具体条件失败。

ingest不能反过来代替release。现实中若管道先收到尚未公开或误标时间的资料，单查入库会让它进入公共信息研究。本文假设四行都满足ingest不早于release，且不处理保密资料，但实现仍同时检查两列，让边界清楚。时间来源若错误，筛选器再严也不能修正上游事实。

版本选择应在筛选之后完成。错误地先保留最终版A2，再按入库截断，会在六分钟把A整源变空，丢掉当时确实已在库的A1；先用最终值再统一延后几分钟，又可能把某个修订提前。保存旧版本是重建系统快照的必要条件，不能只保留最新值和一个更新时间。

三种口径的最终快照怎样对照

A值	A版本	B值	B版本	两源和	决策分钟	口径
100	1	200	1	300	3	公开边界
—	—	200	1	—	3	实际系统
—	—	—	—	—	3	入库额外延迟2分
110	2	200	1	310	6	公开边界
100	1	200	1	300	6	实际系统
100	1	200	1	300	6	入库额外延迟2分
110	2	190	2	300	8	公开边界
100	1	190	2	290	8	实际系统
100	1	200	1	300	8	入库额外延迟2分
110	2	190	2	300	10	公开边界
110	2	190	2	300	10	实际系统
100	1	190	2	290	10	入库额外延迟2分

公开口径三分钟可得A1与B1，总三百；实际系统缺A，只能给B一源，合计不确定。六分钟公开可用A2加B1等于三百一十，实际系统仍A1加B1为三百。八分钟公开A2加B2为三百，实际系统A1加B2为二百九十；十分钟两者才共同采用两源第二版。

这不是认为公开研究必须模拟最慢系统。公共口径可以合理回答“在理想取得公开资料的条件下，哪些版本已经对外可见”；实际口径回答“这套管道当时能拿哪些”。报告应清楚写出研究对象，不能拿公共零延迟成绩宣传为某个实际部署系统已经可实现的结果。

额外延迟两分钟情景把每条ingest统一加二，release保持，体现系统条件变化而非公开事实变化。三分钟两源都不可用；六分钟回到两源第一版合三百；八分钟仍是三百；十分钟A第二版尚未入库，只能A1与B2合二百九十。这个变化说明延迟不一定让某个总量单向变大或变小，取决于修订方向。

迟到和修订同时存在时怎样保持来源

每个决策快照保存实际采用的源行身份和版本，不只保存计算后的和。相同合计三百可能来自A1+B1，也可能来自A2+B2；如果只保留结果，看起来完全一致，研究者却无法判断信息集是否相同。版本和时间是计算结果的组成证据，不是可随意压缩的装饰字段。

多源更新不同步也不等于输入必须取同一个版本号。本例八分钟系统使用A1与B2，这是实际可知组合；强行等两源都到版本二可能改变系统策略，允许不同步又应记录混合状态。真实指标如果要求同一观察期的完整字段，缺一源就拒算，本篇两源和正采用这条完整性政策。

若旧数据在九分钟被后台覆盖成新值，后来再查询六分钟必须仍返回A1。否则入库时间虽然保留，历史存储已经丢失旧值，无法重放。可采用追加版本与双时间查询，而不是在主表上原地更新。本文脚本以有限候选枚举说明逻辑，没有实现数据库事务、并发一致性或消息去重。

缺少接收日志能做怎样的结论

有真实公开时刻而无历史ingest时，仍可做公共信息边界研究，但不能声称已经还原某套实际系统。可以明确给不同延迟假设作为敏感性，像本例额外两分钟那样保留情景标签；不能事后找一个让回测最好看的延迟，再写成真实测得。实际延迟分布需要日志，不能从最终文件下载时刻倒推出全部历史入库时刻。

日期精度也要匹配问题。只有公开日的资料，不能无依据设成当天零点用于日内决策；如果来源仅保证某日更新，可以采用明确保守规则或报告未知。本文全部时间精确到分钟，并明确相等可用；真实系统同分钟顺序不明时应保留序号或做排除等时刻的对照。

原始来源与本篇独立产物

FRED Real-Time Periods的Introduction说明版本所知期间，本文读取该节与日期边界示例，核对日2026年10月24日。FRED说明不提供本篇私有系统入库分钟；这些分钟都是构造输入。merge_asof文档支持向后候选方法，但简单只按release做一次连接不能替代本篇双条件筛选。

本篇不重算同收盘买卖金额，不宣称所有投资者共享同一网络延迟。它交付的是每个决策截点的四维筛选、版本选择和迟到对照。读者可以用同样字段填入自己的日志，再判断哪一个边界与研究目标相符；缺失的时间证据仍应是未知，不能被一个固定偏移参数伪装成历史事实。

数据六项自查母文用于检查总体数据健康。样本分割基础工具只辅助理解训练与检验样本的划分；本篇专门的逐行审计由教学表和标准库脚本完成，工具没有内置这些检查。相关核对可继续阅读行情API分页截断检查、回测数据版本差异复现。

道积君编辑组，AI辅助编写与核算。本文为构造教学样本，公开脚本只使用Python标准库，默认在脚本同目录生成UTF-8、LF换行的JSON；不依赖pandas、网络或仓库。没有实测第三方框架或实际交易系统，不据此推断真实收益、成交或数据源可靠性。

复算资料

本篇编号DJ4-053。下载Python复算脚本（文本）与构造输入输出JSON，按编号核对本篇。脚本改存为.py后可用Python标准库运行，数据不是实际用户记录。