时间戳问题

[KimHu01]

时间戳问题
1.前后端交互及数据库存储，为何不直接使用数字类型的时间戳？

• 对应java的Long类型
• 对应mysql的bigint类型
• 其他数据库也都有类似的类型

使用数字类型时间戳的理由
1.前端/移动端可以根据本地时区及所需的日期时间格式进行解析。
2.后端不再需要考虑时区问题，同时对时间的运算处理，也变成了对数字的运算处理，显然更加方便快捷。
3.前后端交互时，传输数字也不在需要考虑时区问题和格式问题。
4.数据库同样也不再需要考虑时区问题，也无须考虑不同数据库之间日期时间格式和类型的问题；同时查询性能上也有优势。

[iseki0]

首先，不要在 JSON 中传递 Java 中的 Long；关于 JSON 的使用这边建议参考 RFC7493

An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2 ** 53)+1, (2 ** 53)-1]) as an exact value.

其次，请不要尝试对 UNIX 时间戳进行直接的运算，各大语言都提供了非常方便的时间日期函数库，没有任何理由不用。关于数据库，一个实现良好的数据库不应该在这里体现出显著的性能差异。

传递时间戳需要考虑其它的问题，你的时间戳，是标准的 UNIX 时间戳吗，单位是秒还是毫秒？还是纳秒？？起始时间是 1970-01-01T00:00:00Z 吗，关于闰秒呢，处理和 UNIX 时间戳一致吗（就是不处理，忽略）

当然阿里这手册中指出的传输格式也是问题严重，详细内容我在 #983 中指出了

[zqq90]

补充楼上

1. Long 在部分环境是有精度问题的
2. 查询更直观
   • 比如数据库中：'2023-10-18T10:00:00Z' > '2023-10-18'
   • 比如日志中可以直接 grep '2023-10-18'
3. 关于时区：
   • 部分数据库查询时，支持时区转换
   • 有些业务场景需要关注用户时区，保留用户时区
4. 关于性能，代码是给人看的，在很多场景不需要扣这点儿性能
   另外，特殊优化的时间解析性能并没有那么差，理论上都是遍历一遍字符串，最终都是 64bit （根据精度）