时间追踪软件为什么总把时间凑整到十五分钟？

那通电话其实只打了六分钟。软件记下来的却是一刻钟——因为一刻钟是它愿意吐出来的最小单位。一通十四分钟的电话，记下来也是一刻钟；一通十一分钟的，还是一刻钟。三通长短明显不一样的电话，从软件里看出来一模一样，而且没有一通真的打了十五分钟。这个数字不能说是错的，它只是没有在描述任何真实发生过的事——它是这套格式本来就打算吐出来的东西，跟它背后那六分钟对不对得上，无关紧要。

凑整这个规矩，是为发票设计的，不是为你

按固定单位计时——一刻钟，有时是十分之一小时——出自一个很具体的场景：按小时计费，客户是按整块时间付钱的，没人希望账单上出现"一通六分钟的电话，收 4.17 元"这种明细。凑整到一个整齐的单位，能让算账简单、账单好看。对负责开账单的人来说，这是个说得通的办法。可它跟一个只想诚实记下自己一天过成什么样的人，其实没什么关系——但这套规矩还是被大多数时间追踪软件当成默认设置继承了下来，因为这些软件最初就是照着计费场景做的，其他人只是顺带用上了同一套凑整逻辑。

凑整之后的数字，看着精确，其实不然

容易被忽略的是这一点：像"0:15"这样的数字，看上去就是精确的，跟真的量出十五分钟长得一模一样。可它没法告诉你，这条记录底下到底是六分钟还是十四分钟——两种可能都被同一个数字盖过去了。这条记录现在带着的确定感，比它实际拥有的要多。你看到的已经不是当时发生的事，而是那件事被一套只肯输出几个固定数字的机器过滤了一遍之后的样子，事后再也分不清进去的到底是哪个真实数值。

一次的误差很小，攒起来就不小了

凑整一次电话，误差小得没人会在意。但一天很少只有一通电话。一天里被打断八次，每次都往上凑到最近的一刻钟，最后追踪软件可能显示两个小时的"被打断时间"，而实际的打断加起来也许才四十分钟。每一次单独的凑整，当时都感觉不出什么问题。可攒了一整天，再攒一整周，得出的总数就会悄悄跟你实际经历的那一天对不上——不是因为哪里记错了，而是因为软件每次都在你回头看一眼之后，把数字往上抬了一点。

有些事短到连凑整都轮不上

还有反过来的情况，跟前面这个问题挨得很近。一件事如果短到没到软件的最小单位，有时候不会往上凑整，而是直接被抹成零，或者软件压根不会提醒你去记这么短的事。帮同事一个两分钟的小忙、一条起了关键作用的简短消息、一次改变了这一天走向的短暂交谈——都够不着那道门槛，于是都没能留在记录里。这一天确实包含了它们，只是追踪软件从设计上就没打算注意到这么小的事，而一份带着隐形最小尺寸的记录，恰恰会在那些最小、最容易被忘掉的时刻留下盲区。

把时长拿掉，也就没什么可凑的了

以上这些问题，说到底都出自同一个决定：这个工具在测量一段时间的长短，而长短总得用某个单位表达，单位又总得是个固定的大小。一份从一开始就不测量时长的记录，压根没有可以让凑整落脚的地方。写下"跟包工头通了个电话，说改期的事"，不需要凑进十五分钟的格子，也不需要凑进十分钟的格子，或者任何格子——它只需要是真的，而不管这通电话实际打了两分钟还是十二分钟，这句话都一样成立。一行字底下，没有单位在等着把它凑整到最近的哪个数。

TimeMap 就是照这个思路做的，不是碰巧躲开了这个问题：时长从来不是它记录的字段，所以一行字背后不会藏着一个十五分钟的格子，也没有哪个最短长度是一件事必须达到才配被写下来的。你写下自己在做什么，配个颜色，不管这件事实际花了两分钟还是两个小时，这条记录都一样成立——从来没有被凑整过，因为它从来就没有被量过。

如果一个凑整过的数字，曾经显得比它想描述的那一刻更笃定，那份笃定其实是从单位那里借来的，不是记录本身挣来的。一句只说"发生了什么"的话不会有这个毛病，因为它从一开始就没打算变成一个数字。