0

我的 solr 中有一条数据： 使用 Solr 管理用户界面，修改时间为“2016-04-20T13:58:35.805Z”。

使用 solrj： 在此处输入图像描述，修改时间为“Wed Apr 20 21:58:35 CST 2016”。

我正在使用solr6。为什么？

4

2 回答 2

3

来自 Solr Administration User Interface 的 modifyTime 数据格式为 UTC，可以通过 datetime 字符串末尾的 Z 来理解，表示该字符串表示的日期是 UTC。

2016-04-20T13:58:35.805Z

另一方面，来自数据格式的 modifyTime 是 CST –中国中部 标准时间，在您的情况下，它似乎是 + 8 小时。

Wed Apr 20 21:58:35 CST 2016

发生这种情况是因为 java.util.Date 没有时区但它的 toString 方法应用 JVM 的当前默认时区的 Java 烦人且糟糕的功能。

java.util.Date date = ( java.util.Date ) doc.getFieldValue("modifyTime");
DateTime dateTimeUtc = new DateTime( date, DateTimeZone.UTC );
String output = dateTimeUtc.toString();

编辑

感谢@BasilBourque 对CST（时区缩写）含义的建议

于 2016-07-26T13:43:24.430 回答
1

中国标准时间 (CST)

阿尔弗雷多的答案是正确的，但有一个假设。该答案提到中央标准时间，但该区域落后于UTC（7 或 6 小时），而问题中的数据领先于 UTC。所以我假设CST这里指的是中国标准时间，比世界标准时间早 8 点。

这种混淆说明了为什么我们不应该使用这些 3-4 个字母的缩写，例如CST. 它们不是真正的时区，不是标准化的，甚至不是唯一的（正如我们在这里看到的）。而是使用适当的 tz/IANA 时区，格式为continent/region.

java.time

问题是使用旧的日期时间类。在 Java 8 和后来的 java.time 框架中，这些设计不佳且臭名昭著的类已被取代。

应该直接解析该字符串Instant以获取UTC中的值。

Instant instant = Instant.parse( "2016-04-20T13:58:35.805Z" );

调用toString以获取根据ISO 8601标准格式化的相同类型的字符串。

应用时区以通过特定地区的挂钟时间的镜头看到同一时刻。应用 aZoneId来获取一个ZonedDateTime对象。

例如，America/Montreal挂钟时间比 UTC 晚四小时，所以小时09而不是13.

ZoneId zoneId = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone( zoneId );

2016-04-20T09:58:35.805-04:00[美国/蒙特利尔]

Instant和都ZonedDateTime代表时间线上的同一个同时点。

于 2016-07-26T16:08:24.643 回答