这是一个创建于 3224 天前的主题，其中的信息可能已经有所发展或是发生改变。
答案可能不是绝对的, 请大家依据不同项目情况分享下自己的经验.
针对一个 Web 项目, 数据库(PostgreSQL)储存时间戳的时候, 有人用 bigint, 有人用 timestamp.
1. bigint
时间戳由后端(Node.js)生成, 填入数据库.
用的时候由前端 /后端来格式化.
时间戳为精确到毫秒的整数型, 前后端处理起来比较一致. 数据库想要操作可以用 to_char().
2. timestamp
时间戳由数据库生成.
用的时候由数据库格式化或数据库格式为 UNIX 时间戳(可额外携带精度)交给前后端格式化.
timestamp 可选精度值.
想要输出 Javascript 的时间戳 SQL 比较嗦, 比如 (EXTRACT(EPOCH FROM add_time) * 1000)::bigint
在数据库有余力的情况下, 我目前的做法是数据库存为 timestamp, 输出 Javascript 格式的时间戳, 由前端格式化.
针对一个 Web 项目, 数据库(PostgreSQL)储存时间戳的时候, 有人用 bigint, 有人用 timestamp.
1. bigint
时间戳由后端(Node.js)生成, 填入数据库.
用的时候由前端 /后端来格式化.
时间戳为精确到毫秒的整数型, 前后端处理起来比较一致. 数据库想要操作可以用 to_char().
2. timestamp
时间戳由数据库生成.
用的时候由数据库格式化或数据库格式为 UNIX 时间戳(可额外携带精度)交给前后端格式化.
timestamp 可选精度值.
想要输出 Javascript 的时间戳 SQL 比较嗦, 比如 (EXTRACT(EPOCH FROM add_time) * 1000)::bigint
在数据库有余力的情况下, 我目前的做法是数据库存为 timestamp, 输出 Javascript 格式的时间戳, 由前端格式化.
 | 1 jingniao 2017-02-06 17:30:07 +08:00 目前都是 int 类型的时间戳，转换大部分是在返回给前端的时候做下，也偶尔让前端自己转 主要是清晰，如果用数据库自带的 timestamp ，在转换的时候有时候会晕，本地时间， utc 时间，还有时区问题，所以我宁愿存储成 unix 样式的时间戳。 |
 | 2 hheedat 2017-02-06 17:35:03 +08:00 时间戳格式化应该由前端完成，前端根据设计自行决定显示的格式 |
 | 5 wizardforcel 2017-02-06 18:33:10 +08:00 via Android 前端 |
 | 6 learnshare 2017-02-06 19:35:51 +08:00 via Android 展示端格式化，传输和计算都尽量保证统一的格式，比如用毫秒值 |
 | 7 owt5008137 2017-02-07 09:08:47 +08:00 via Android unix 时间戳兼容性最高哇，毫秒时间戳支持的语言并不多。逻辑时间操作一般直接用 UTC 时间戳，避免时区和闰秒问题。显示部分当然谁要显示谁转成 local time 了，这样即便不同时区显示的时间也是一样的 |
 | 8 jarlyyn 2017-02-07 10:20:59 +08:00 必然是前端转最好。 |
 | 9 otakustay 2017-02-07 11:43:02 +08:00 一切格式化的工作尽量靠近前端，能靠多近就多近 |
 | 10 suikatw 2017-02-07 13:25:00 +08:00  1 这个问题我也想了解和探讨一下 可能场景不太一样 我喜欢用数据库来做，因为我最担忧的是机器时间意外不准的情况下如何保证逻辑正确 考虑到前端应用、后端应用都是多台机器，而数据库在不分库的情况下基本上请求都是打到同一台机器上，这样可以保证时间是统一的，不必过于担忧如果系统里各台机器时间不一致导致的逻辑 bug |
 | 11 flyico 2017-02-0713:52:40 +08:00 按说应该是前端来处理格式 但是很多时候我们也会加上格式化好的数据 主要是为了自己调试起来方便查看 |
 | 12 julyclyde 2017-02-07 21:36:35 +08:00 时间戳遇到闰秒会丢失信息量 |
Select Language