V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 3371 days ago, the information mentioned may be changed or developed.
答案可能不是绝对的, 请大家依据不同项目情况分享下自己的经验.
针对一个 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 Feb 6, 2017
目前都是 int 类型的时间戳，转换大部分是在返回给前端的时候做下，也偶尔让前端自己转
主要是清晰，如果用数据库自带的 timestamp ，在转换的时候有时候会晕，本地时间， utc 时间，还有时区问题，所以我宁愿存储成 unix 样式的时间戳。 |
 |
2
hheedat Feb 6, 2017
时间戳格式化应该由前端完成，前端根据设计自行决定显示的格式
|
 |
5
wizardforcel Feb 6, 2017 via Android
前端
|
 |
6
learnshare Feb 6, 2017 via Android
展示端格式化，传输和计算都尽量保证统一的格式，比如用毫秒值
|
 |
7
owt5008137 Feb 7, 2017 via Android
unix 时间戳兼容性最高哇，毫秒时间戳支持的语言并不多。逻辑时间操作一般直接用 UTC 时间戳，避免时区和闰秒问题。显示部分当然谁要显示谁转成 local time 了，这样即便不同时区显示的时间也是一样的
|
 |
8
jarlyyn Feb 7, 2017
必然是前端转最好。
|
 |
9
otakustay Feb 7, 2017
一切格式化的工作尽量靠近前端，能靠多近就多近
|
 |
10
suikatw Feb 7, 2017  1
这个问题我也想了解和探讨一下
可能场景不太一样 我喜欢用数据库来做，因为我最担忧的是机器时间意外不准的情况下如何保证逻辑正确 考虑到前端应用、后端应用都是多台机器，而数据库在不分库的情况下基本上请求都是打到同一台机器上，这样可以保证时间是统一的，不必过于担忧如果系统里各台机器时间不一致导致的逻辑 bug |
 |
11
flyico Feb 7, 2017
按说应该是前端来处理格式
但是很多时候我们也会加上格式化好的数据 主要是为了自己调试起来方便查看 |
 |
12
julyclyde Feb 7, 2017
时间戳遇到闰秒会丢失信息量
|
Select Language