主题：真心，虚心请教软件人士，这些看似反智的变化背后有什么原因 -- dfindy

我最后一句话也说了，可能有比你所吐槽的更好的表达方式。

“现在是11/6/2022,11/1/2022是五天前”很简单不错。那么我们再做一个小测试，10/27/2022是几天前？从现在开始计时——1、2、3——算算自己花了多长时间？

这还只是跨月的计算，如果是2月跨3月，还要考虑闰年……

上面这段是想表明，计算再简单也是需要时间和精力的，哪怕只有一点点。

独立计算一个时间段，任何一个受过正常教育的成年人都没有问题，跨月毫无问题，闰年也不在话下。但是当多个时间段以某种排列呈现出来时，如何让用户扫一眼就能得到一个大致的第一印象，足以供其为所关心的事务排序或定性？这个问题的解答其实并没有简单答案，特别是Outlook或者苹果日历这种面向最广大用户的通用软件而言。

其实就是我们现在用的格里高利历，也不过是相对于两千零二十二年前的某一天而已，也就是说，所谓的“绝对”时间，其实也是相对的，只不过参照系的选取不同而已。所以你这个2027-1976=51的例子，有其合理性与适用范围，但不能与“XX时间以前”这样的相对表达方式互相否定。当然了，体现在Outlook这样的软件上，事实上是“XX时间以前”的表达方式否定了相对于公元0年的表达方式，这一点我前面说了，不排除可能有比你所吐槽的更好的表达方式。

作为这一类通用软件的用户，我并不反对你在日历问题上的某些看法。作为项目里不同的角色，习惯从自身的角度看问题的同时从用户/客户/老板/任何其它第三方的角度看问题，这样才能发现彼此的盲点。但即便洞察了所有问题所在，也不是所有问题都能得到令所有人满意的解决，最终得到的仍然是“质量-成本-进度不可能三角”。

说说sophisticated用户吧。

对企业而言，无它，利润而已，只要最unsophisticated用户代表了最大的利润，那么sophisticated用户就是牺牲的代价。除非sophisticated用户unsophisticate的难度大于unsopisticated用户sophisticate的难度，否则企业合理的选择一定是“强迫其它用户捏着鼻子作牺牲”。当然也不排除sophisticated用户嗓门大，迫使企业或组织走回头路的可能。稍有点历史底蕴的公司都曾面对过这种情况，这不过是试错成本，历史越辉煌这种试错成本越高。而对于像vim或者EMACS这样历史渊源几十年的软件而言，sophisticated用户简直是一言九鼎，这类人现在被赋予一个新名词：头部用户。

sophisticated是否有价值的关键是，对社会而言，如果这样能够提高劳动效率，那么熟练心算时间段的技术就沦为屠龙计。

说到sophisticated用户的屠龙计，想起马克吐温的《在密西西比河上》，发散一段。

马克吐温年轻的时候第一份正经工作就是在密西西比河上作领航员。密西西比水文复杂多变，通航不易，所以那年月领航员是一个需要高超技术和丰富经验的职业，受人尊敬的程度不亚于船长。和海员一样，这一行论起年资来也等级森严，越老越吃香，毕竟经验的累积是需要时间的。

但是到了马克吐温入行的时候，密西西比河上出现了新事物。年轻的领航员们成立了一个组织，在密西西比沿岸各码头设点，组织内部的领航员每领一艘船靠岸，便到码头详细报告沿途水文变化，同时领取下一个航段最新的水文报告。这一来资深领航员不论多丰富的经验也敌不过群策群力，密西西比河上的领航业务生生被这一群初生牛犊夺去了大半。

我一直把这看作开源组织的发端，哈哈。