找回密码
 立即注册

QQ登录

只需一步,快速开始

数据民工 悬赏达人认证 活字格认证

高级会员

34

主题

801

帖子

1565

积分

高级会员

积分
1565

时代开发者征文活动悬赏达人活字格高级认证活字格认证

数据民工 悬赏达人认证 活字格认证
高级会员   /  发表于:2023-1-5 19:43  /   查看:1971  /  回复:3
在服务端命令里与页面设置里,设置同样的Excel命令,得到的值不同,是BUG?还是计算模式不同?

页面得到的对比结果

以下是页面上的设置


以下是服务端命令里的设置


具体公式为=TODAY()-DATE(1900,1,0)
在Excel里计算结果与服务端命令里是一致的,与页面命令里变量输出值不同

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

3 个回复

倒序浏览
Simon.Sun活字格认证 Wyn认证
超级版主   /  发表于:2023-1-6 10:08:03
沙发
本帖最后由 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) 这个公式的计算的结果,不管是服务端还是设计器页面,都是一致的。



回复 使用道具 举报
数据民工悬赏达人认证 活字格认证
高级会员   /  发表于:2023-1-6 22:48:23
板凳
Simon.Sun 发表于 2023-1-6 10:08
这个问题这边复现反馈下,有结果会继续再跟进。

问题跟进:

你说的这个故事我很早之前就了解,主要是不知道为啥同一个产品结果不同罢了,既然是这样,那我就知道了,在构建公式的时候加减1就行了

评分

参与人数 1金币 +5 收起 理由
Simon.Sun + 5 很给力!

查看全部评分

回复 使用道具 举报
Simon.Sun活字格认证 Wyn认证
超级版主   /  发表于:2023-1-9 09:36:21
地板
大佬厉害,说实话不是大佬反馈,我都不知道 Excel 还有这个 bug。
关于原因上面回复有所涉及,活字格页面端和服务器端的 Excel 公式支持使用分别使用到了葡萄城另外两款产品 SpreadJS 和 GCExcel。
SpreadJS 解决了 Excel 的这个问题, GCExcel 选择了和 Excel 保持一致,这个现象可以看做是一个限制吧。

解决方案就如同大佬所说处理下数据,详细来说就是计算跨越了 1900-3-1 这个时间的日期差时,在服务端计算的结果要减 1,就可以得到正确的计算结果。
回复 使用道具 举报
您需要登录后才可以回帖 登录 | 立即注册
返回顶部