想请教下大家序列化都用什么库，怎么保存时间格式的？

[zhdsuperm]

我们基本上都用的 jackson，还有小伙伴用 fastjson 吗？时间都是统一保存 64 位时间戳格式，都丢给前端处理

序列化踩坑

[nikandaoleshenme]

1，序列化方案取决于业务场景，通常的文本数据传输使用 json 格式，不能使用 json 格式的就需要私有协议和自定义序列化规则

2，对于计算机来说，时间只是一个数字，所以存储、传输、计算 时间操作最优解肯定是数字格式，但对于自然人来说就不是了，建议：若程序服务的用户都在一个 行政时区 内，那使用当地时区时间格式无疑是最为方便的，对于程序也是一致的。若不是，使用数字格式最为通用，最终的时间格式展示只需要转换为当地时间即可

[fumichael]

64 位时间戳？？？ 13 位或者 10 位吧

[Mutoo]

时间请用 ISO8601 标准格式，记得带上时区信息。

[Rwing]

你发在程序员节点上，你让其他语言的人一头雾水啊，还是说，现在程序员默认都是 java 语言了？

[beidounanxizi]

@Mutoo 别误导了 你用 iso8601 谁知道什么格式 更多的不会带上时区， 序列化成字符串的时候 很多人不会带上时区的

[qwerthhusn]

@fumichael 毫秒时间戳，是 64 位的，这个位是 bit 。用 10 进制表示就是十来位（数字的位数）

[beidounanxizi]

fastjson / jackson 注解上 或者自己写个自定义注解，
在 jdk8 和 老的时间库上面
传输格式用 unix 时间戳 数字 默认是秒精度

[beidounanxizi]

自定义序列化 /反序列化 处理器

[CoderGeek]

时间戳

[realpg]

@fumichael
64 bit
not 64 length string

[zpf124]

@fumichael 他说的是数据类型， 指 64 位精度的整型数字。 java 里是 long，mysql 里叫 bigint 。
意思就是他是转成时间戳发送给前台的。

[fumichael]

@qwerthhusn #6 @realpg #10
好的好的，学习了

[swulling]

最早我也觉得时间戳更好，没有格式、时区等问题。
但是如果 API 是给前端使用的，我觉得 ISO8601 （含时区）会更好一些，调试起来更方便。心智成本比较低。

[Mutoo]

@beidounanxizi ISO8601 是业界标准，基本上所有标准库都支持的。转换也是由标准库完成的，难道你手工拼字符串吗？在 i18n 成为刚需的今天，时区信息其它上必不可少。哪怕你不在 ISO8601 里体现，至少得到的也是 UTC 时间（ 0 时区）是安全的。

[qwerthhusn]

现在 java8 的 date-time 的 api 普及率很低啊。

项目不会涉及到时区就用 LocalDateTime，涉及到时区用 ZonedDateTime
日期类型用 LocalDate/ZonedDate

jackson 默认序列化出来的是 ISO8601 格式的

[Chappako]

编程语言也不说，上来在程序员节点问，你这不耍流氓么？

[cmdOptionKana]

由于涉及前端，所以我也是用 ISO8601，这个格式 JavaScript 处理起来方便。

[zpf124]

@beidounanxizi
@Mutoo
使用 IOS8601 其实确实是最理想的方式， 因为可以直接看明白，时间戳是没法肉眼辨认时间的。
但实际开发中则还是时间戳对于开发人员而言方便，尤其是调用接口的项目存在多种而且还不是一个团队一个代码风格的时候。

另外 带时区信息 不如格式化成 UTC 时间方便， 带时区不如而时间戳对于开发人员更方便，就是因为不同代码风格不同开发人员的水平、使用的类库和工具对于 ios8601 默认序列化表达式处理不一定一致。

[Mutoo]

@zpf124 ISO8601 的好处是不受语言、底层表达范围（ 32/64bit ）的影响，哪怕最终的表示不一致，但所含的信息是一致的。另外时区可以作为额外的字段，也可以直接在 ISO8601 里体现，是附加价值。

[janxin]

用 RFC3339

最好带时区，只在国内用的应用没这种烦恼...