为何Instant转Epoch毫秒再转回后不相等？如何正确存储到数据库

为什么代码的compareTo返回值不为0？ #

Instant.now() 获取的是纳秒精度的当前UTC时间，而 toEpochMilli() 方法会将时间转换为毫秒级单位——这一步会直接丢弃纳秒部分的信息。当你用 Instant.ofEpochMilli() 将毫秒值转回Instant时，生成的新实例的纳秒字段会被设为0，而原始的now实例还保留着完整的纳秒数值（比如你示例里的897000纳秒）。因为纳秒部分的差异，原始now的时间戳比转换后的实例更“晚”，所以compareTo方法会返回正数，两者自然不相等。

你可以打印两个Instant的字符串形式来直观验证：

Instant now = Instant.now();
Instant fromMilli = Instant.ofEpochMilli(now.toEpochMilli());
System.out.println(now);          // 示例输出：2024-05-20T12:34:56.123456789Z
System.out.println(fromMilli);    // 示例输出：2024-05-20T12:34:56.123000000Z

能明显看到后者的纳秒部分被截断为0。

正确的数据库存储Instant的方式 #

根据你的数据库对时间精度的支持情况，选择对应的方案：

• 数据库支持纳秒精度（如PostgreSQL的TIMESTAMP WITH TIME ZONE）：使用JDBC 4.2及以上版本的驱动，直接通过PreparedStatement.setObject(..., instant)写入，用ResultSet.getObject(..., Instant.class)读取，能完整保留纳秒级精度。
• 数据库仅支持毫秒精度（如MySQL的DATETIME/TIMESTAMP）：
  • 接受精度损失的话，存储前可将Instant截断到毫秒级：instant.truncatedTo(ChronoUnit.MILLIS)，再按毫秒值或对应时间类型存储。
  • 想保留全精度的话，可将Instant转为字符串（instant.toString()）存储，恢复时用Instant.parse()解析，这种方式能完整保留所有信息，但查询时的时间范围操作可能不如原生时间类型便捷。
• 通用数值存储方案：将Instant转换为从纪元开始的总纳秒数（计算方式：instant.toEpochMilli() * 1_000_000 + instant.getNano()），用数据库的大整数类型（如PostgreSQL的BIGINT）存储。恢复时拆分回毫秒和纳秒，通过Instant.ofEpochMilli(nanos / 1_000_000).plusNanos(nanos % 1_000_000)还原为Instant。

内容的提问来源于stack exchange，提问作者Eve