本帖最后由 Simon.Sun 于 2023-1-6 17:46 编辑
这个问题这边复现反馈下,有结果会继续再跟进。
问题跟进:
这个现象起源于 Excel 的一个陈年老 bug:
Microsoft Excel 的陈年旧 bug (azaleasays.com)
简单来讲就是, 在 Windows 操作系统上的 Excel 版本中,日期系统默认为 “1900 年日期系统”,即 1900 年 1 月 1 日作为日期序列值的起始日,1900/1/1 的序列值为 1,1900/1/1 的序列值为 2,依次类推。然后这个 1900 年日期系统认为 1900 是润年,所以 2 月有 29 号,实际上 1900 年为平年。
举个例子:DATE(1900,3,1)-DATE(1900,2,28) 正常得到的结果应该为 1,但由于 Excel 的 bug,得到的结果为 2。
上面的结果再或者页面端得到的结果为 1,服务端得到的结果为 2。服务端计算公式基于葡萄城的产品 GCExcel,这个日期行为和 Excel 保持一致,页面端为 1 是因为活字格页面端的 Excel 公式时基于葡萄城另外一款产品 SpreadJS,而 SpreadJS 避免了 Excel 的这个陈年老 bug(SpreadJS 还是牛)。
说下结论:
起始原因是由于 Excel 的 bug,服务端选择了和 Excel 保持一致,设计器页面则解决了这个问题。但也不能说这两种选择谁对谁错,一个选择了行为一致,一个选择了正确。
如果想让服务端和设计器页面保持一致,计算日期差值时,避免跨越 1900-3-1 这个分割线就行。比如 DATE(1900,3,5)-DATE(1900,3,1) 和 DATE(1900,2,28)-DATE(1900,2,17) 这个公式的计算的结果,不管是服务端还是设计器页面,都是一致的。
|