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

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

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

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

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

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

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

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

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

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

时间戳

@fumichael
64 bit
not 64 length string

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

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

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

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

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

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

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

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

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

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

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

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

用 RFC3339

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

@Mutoo
@zpf124

理解你们说的， 但是确实开发人员风格不同，导致时间千奇八怪，以及序列化库在时间字段的处理上不同，用 ISO8601 这个如果写在代码审查上是没毛病的。

最通用的肯定是 ISO8601 和毫秒时间戳，前者方便阅读，后者方便开发。
作为开发者，两种我都用过，还是强烈推荐毫秒时间戳，用起来比 ISO8601 舒服多了，ISO8601 传输时毕竟还是字符串，总是需要 format，挺烦的。

我倾向于毫秒时间戳，Javascript 官方标准好像没有要求支持 ISO8601 的解析，全靠浏览器支持、js 引擎支持，或者项目中引入第三方库。
我之前的项目中有遇到 js 解析 ISO8601 字符串，我使用 new Date('ISO8601 字符串')，在基于 chromium 的浏览器上能正确解析，但是在 macOS 的 safari 或者 iOS 的 webview 上好像是报错的。

只用时间戳，有可读性需要再单独转