【发布时间】:2018-04-22 06:25:18
【问题描述】:
使用 Java Date 对象,最简单的方法是将它们存储为 MySql DateTime 对象(以 UTC 为单位)。切换到Instant 后,这种方法将不再适用,因为 MySQL DateTime 不提供存储纳秒的精度。仅仅截断它们可能会导致新创建的 Instant 对象与从数据库中读取的对象之间出现意外的比较结果。
BigDecimal 时间戳在我看来并不是一个优雅的解决方案:手动编写选择查询变得更加困难,因为您必须在各处转换时间戳以使其可读,并且与 Instant 相比,Java 中的处理有些笨拙甚至Long 值。
去这里最好的方式是什么?应该不是varchar吧?
【问题讨论】:
-
@OleV.V.好的,但 MySQL 文档似乎暗示时间戳最多只能处理微秒。纳秒部分会发生什么?
-
有趣的问题,@TimBiegeleisen。 The docs 似乎证实了这一点。看来我们必须要有创意。
-
当然我可以将两个
Instant组件存储在两列中,这会使事情变得更加复杂。我只是想知道对于这个不那么奇怪的问题是否有一个通用且方便的解决方案。 -
我想不出比你更好的建议。如果您在偏移量
ZoneOffset.UTC处将Instant转换为OffsetDateTime并使用uuuu-MM-dd'T'HH:mm.ss.SSSSSSSSSX对其进行格式化,那么(1)直到9999 年,您的字符串将始终为30 个字符(2)可以将字符串直接解析回Instant(3) 字符串的顺序将与瞬间的顺序相同,并且 (4) 数据库中的字符串将比纯数字更具可读性。 -
@Basil Bourque 你说得对,我真的不需要它们。事实上,即使是 documentation 的
Instant也不鼓励依赖它们。我只是想避免在运行时创建的Instant不等于存储并从数据库重新加载的Instant的情况,只是因为 nanos 丢失了。这是一个未记录的副作用,可能会搞砸 UnitTest 或更糟。
标签: java mysql date datetime java.time.instant