Cassandra插入UTC时间被重复转换的问题及解决咨询

我之前也踩过类似的坑，本质是Cassandra的timestamp类型本身只存储毫秒级Unix时间戳（不带时区信息），问题出在输入时间时的解析时区设置，而非Cassandra主动“再次转换UTC”。你的本地时区是GMT+5，cqlsh默认会把你输入的时间字符串当成本地时区时间，再转成UTC存储，所以才会出现自动减5小时的情况。下面是几种靠谱的解决方法：

1. 在cqlsh中插入UTC时间的正确姿势 #

• 明确标记UTC时间字符串：在时间末尾加上Z（代表UTC时区），这样cqlsh会直接把它解析成UTC时间，不会用本地时区做转换：

  INSERT INTO myTable (id, time) VALUES ('abc123', '2018-01-12T12:32:31Z');
  

• 全局设置cqlsh使用UTC时区：
  • 启动cqlsh时直接加参数：cqlsh --utc
  • 或者进入cqlsh后执行命令：

    SET TIMEZONE TO 'UTC';
    

    之后所有输入的时间字符串都会被当成UTC解析，不用每次手动加Z。

2. 应用程序代码中插入的正确处理 #

不管你用什么语言的Cassandra驱动，核心原则是直接传递明确的UTC时间对象或时间戳数值，不要传不带时区的本地时间字符串/对象：

• Java：使用Instant（本身就是UTC时间）或者OffsetDateTime.of(..., ZoneOffset.UTC)构建时间对象后传入
• Python：传递带UTC时区的datetime对象，比如datetime.datetime(2018,1,12,12,32,31, tzinfo=datetime.timezone.utc)，或者直接传毫秒级Unix时间戳（比如1515760351000）
• 绝对避免传递不带时区信息的datetime对象，否则驱动会自动用本地时区转成UTC，导致和你遇到的一样的错误。

3. 验证存储结果是否正确 #

查询的时候也要注意时区设置，否则显示的时间会被自动转成本地时区：

• 在cqlsh中先执行SET TIMEZONE TO 'UTC';，再查询就能看到存储的原始UTC时间
• 或者直接查询时间戳的数值形式，确认是否符合预期：

  SELECT id, unixTimestampOf(time) FROM myTable;
  

  这个数值对应的就是UTC时间的毫秒级时间戳，你可以用时间戳转时间的工具验证是否和你想要的时间一致。

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