时间戳问题
1.前后端交互及数据库存储，为何不直接使用数字类型的时间戳？
- 对应java的Long类型
- 对应mysql的bigint类型
- 其他数据库也都有类似的类型
使用数字类型时间戳的理由
1.前端/移动端可以根据本地时区及所需的日期时间格式进行解析。
2.后端不再需要考虑时区问题，同时对时间的运算处理，也变成了对数字的运算处理，显然更加方便快捷。
3.前后端交互时，传输数字也不在需要考虑时区问题和格式问题。
4.数据库同样也不再需要考虑时区问题，也无须考虑不同数据库之间日期时间格式和类型的问题；同时查询性能上也有优势。
2条答案
按热度按时间628mspwn1#
首先，不要在 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 中指出了
ehxuflar2#
补充楼上
查询更直观
比如数据库中：
'2023-10-18T10:00:00Z' > '2023-10-18'比如日志中可以直接 grep '2023-10-18'
关于时区：
部分数据库查询时，支持时区转换
有些业务场景需要关注用户时区，保留用户时区
关于性能，代码是给人看的，在很多场景不需要扣这点儿性能
另外，特殊优化的时间解析性能并没有那么差，理论上都是遍历一遍字符串，最终都是 64bit （根据精度）