先看规范改变的是哪一步
阅读区块链时间戳资料时，BIP113提供了一个具体问题：检查时间型锁定约束时，用哪个时间作为比较基准？该规范改变的是判定所用的时间计算方式，而不是把交易中记录的锁定值改写成另一个数。本文只讨论这一局部机制，不构造或提交交易。
规范使用此前区块时间的中位数，代替包含交易的那个区块自身的时间戳参与相应检查。这里的“此前”很重要：它不是把浏览器当前显示的时刻代入，也不是任选一条最新日志。完整交易是否可接受仍有其他条件，不能只靠这一个比较给出结论。
历史窗口要从上一块开始确定
BIP113示例以pindexPrev作为中位时间计算的起点，沿父区块向后收集时间。已有足够历史时，窗口包含十一块；排序后取中间位置。待检查区块自己的时间不在这组此前区块的样本中，这与先把当前候选时间塞进去再求中位数不同。
为了便于复核，一份教学计算表可以先按链上顺序保留这十一块的标识和原始值，再另建排序副本。这样可以分别检查窗口是否选对、是否遗漏或重复了一块、排序结果是否正确。这个表是阅读规范的辅助办法，不替代节点实现，也不要求公开任何账户资料。
中间位置要在数值排序之后取
下面只用玩具整数演示排序，不把它们当真实区块时间：2、12、5、10、7、3、11、4、9、8、6。按数值升序排列后是2到12，十一项中的第六项为7。原始序列的第六项是3，所以直接取输入列表的中间一项，会得到不同答案。
中位数也不是把所有值相加再除以数量的操作。这个例子恰好两种算法都得到7，但这只是所选样本的特点，不能据此把两种定义混同。例如把最大项12改为100，中位数仍为7，算术平均值则改变；例子用来说明算法区别，不表达任何网络现状。
在网页复算时别依赖默认字符排序
若用JavaScript做教学复算，MDN说明Array.sort默认会把元素转为字符串再比较。对上面的玩具数组，这会得到10、11、12、2、3、4、5、6、7、8、9，中间项变成4。数值升序需要明确的数值比较规则，不能因为函数叫排序就假定它按大小处理。
MDN还指出sort会原地改变数组，因此保留原顺序用于检查时，应先复制再排序。最终核对要同时保留样本来源、窗口起点、数值类型和排序规则；有空值或无法解释的输入时先补齐材料，不拿零填空。本文不承诺交易会在某个钟表时刻入块，也不把这组示例当作完整共识验证程序。