这是一个创建于 1600 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们基本上都用的 jackson，还有小伙伴用 fastjson 吗？时间都是统一保存 64 位时间戳格式，都丢给前端处理
 |
1
nikandaoleshenme 2020-08-11 13:17:44 +08:00
1，序列化方案取决于业务场景，通常的文本数据传输使用 json 格式，不能使用 json 格式的就需要私有协议和自定义序列化规则
2，对于计算机来说，时间只是一个数字，所以存储、传输、计算 时间操作最优解肯定是数字格式，但对于自然人来说就不是了，建议：若程序服务的用户都在一个 行政时区 内，那使用当地时区时间格式无疑是最为方便的，对于程序也是一致的。若不是，使用数字格式最为通用，最终的时间格式展示只需要转换为当地时间即可 |
 |
2
fumichael 2020-08-11 13:39:03 +08:00
64 位时间戳？？？ 13 位或者 10 位吧
|
 |
3
Mutoo 2020-08-11 13:42:47 +08:00  1
时间请用 ISO8601 标准格式，记得带上时区信息。
|
 |
4
Rwing 2020-08-11 13:43:58 +08:00
你发在程序员节点上，你让其他语言的人一头雾水啊，还是说，现在程序员默认都是 java 语言了？
|
 |
5
beidounanxizi 2020-08-11 13:56:18 +08:00
@Mutoo 别误导了 你用 iso8601 谁知道什么格式 更多的不会带上时区， 序列化成字符串的时候 很多人不会带上时区的
|
 |
6
qwerthhusn 2020-08-11 13:57:57 +08:00
@fumichael 毫秒时间戳，是 64 位的，这个位是 bit 。用 10 进制表示就是十来位（数字的位数）
|
|
7
beidounanxizi 2020-08-11 13:58:39 +08:00
fastjson / jackson 注解上 或者自己写个自定义注解，
在 jdk8 和 老的时间库上面 传输格式用 unix 时间戳 数字 默认是秒精度 |
|
8
beidounanxizi 2020-08-11 13:59:23 +08:00
自定义序列化 /反序列化 处理器
|
 |
9
CoderGeek 2020-08-11 13:59:44 +08:00
时间戳
|
 |
11
zpf124 2020-08-11 14:02:25 +08:00
@fumichael 他说的是数据类型， 指 64 位精度的整型数字。 java 里是 long，mysql 里叫 bigint 。
意思就是他是转成时间戳发送给前台的。 |
|
12
fumichael 2020-08-11 14:02:36 +08:00
|
 |
13
swulling 2020-08-11 14:04:54 +08:00
最早我也觉得时间戳更好，没有格式、时区等问题。
但是如果 API 是给前端使用的，我觉得 ISO8601 （含时区）会更好一些，调试起来更方便。心智成本比较低。 |
|
14
Mutoo 2020-08-11 14:05:40 +08:00
@beidounanxizi ISO8601 是业界标准，基本上所有标准库都支持的。转换也是由标准库完成的，难道你手工拼字符串吗？在 i18n 成为刚需的今天，时区信息其它上必不可少。哪怕你不在 ISO8601 里体现，至少得到的也是 UTC 时间（ 0 时区）是安全的。
|
|
15
qwerthhusn 2020-08-11 14:06:46 +08:00
现在 java8 的 date-time 的 api 普及率很低啊。
项目不会涉及到时区就用 LocalDateTime，涉及到时区用 ZonedDateTime 日期类型用 LocalDate/ZonedDate jackson 默认序列化出来的是 ISO8601 格式的 |
 |
16
Chappako 2020-08-11 14:08:40 +08:00
编程语言也不说，上来在程序员节点问，你这不耍流氓么？
|
 |
17
cmdOptionKana 2020-08-11 14:09:56 +08:00
由于涉及前端，所以我也是用 ISO8601，这个格式 JavaScript 处理起来方便。
|
|
18
zpf124 2020-08-11 14:20:57 +08:00
@beidounanxizi
@Mutoo 使用 IOS8601 其实确实是最理想的方式， 因为可以直接看明白，时间戳是没法肉眼辨认时间的。 但实际开发中则还是时间戳对于开发人员而言方便，尤其是调用接口的项目存在多种而且还不是一个团队一个代码风格的时候。 另外 带时区信息 不如格式化成 UTC 时间方便， 带时区不如而时间戳对于开发人员更方便，就是因为不同代码风格不同开发人员的水平、使用的类库和工具对于 ios8601 默认序列化表达式处理不一定一致。 |
|
19
Mutoo 2020-08-11 14:26:18 +08:00
@zpf124 ISO8601 的好处是不受语言、底层表达范围（ 32/64bit ）的影响，哪怕最终的表示不一致，但所含的信息是一致的。另外时区可以作为额外的字段，也可以直接在 ISO8601 里体现，是附加价值。
|
 |
20
janxin 2020-08-11 14:38:39 +08:00
用 RFC3339
最好带时区，只在国内用的应用没这种烦恼... |
|
21
beidounanxizi 2020-08-11 14:56:41 +08:00
|
 |
22
wakzz 2020-08-11 15:16:46 +08:00
最通用的肯定是 ISO8601 和毫秒时间戳，前者方便阅读，后者方便开发。
作为开发者，两种我都用过，还是强烈推荐毫秒时间戳，用起来比 ISO8601 舒服多了，ISO8601 传输时毕竟还是字符串，总是需要 format，挺烦的。 |
 |
23
gdtdpt 2020-08-11 15:59:24 +08:00
我倾向于毫秒时间戳，javascript 官方标准好像没有要求支持 ISO8601 的解析，全靠浏览器支持、js 引擎支持，或者项目中引入第三方库。
我之前的项目中有遇到 js 解析 ISO8601 字符串，我使用 new Date('ISO8601 字符串')，在基于 chromium 的浏览器上能正确解析，但是在 macOS 的 safari 或者 iOS 的 webview 上好像是报错的。 |
 |
24
lix7 2020-08-12 13:03:49 +08:00
只用时间戳，有可读性需要再单独转
|
Select Language