问题标签 [jsr310]

我正在公司中用 Java 8 编写新项目。我建议使用 Java 8 日期时间 API，但我的一位同事说新的日期时间 API 运行缓慢。

这是真的吗？此外，我想从 Oracle 获得一些官方文档，其中会提到您不应该java.util.Date在新项目中使用。

我有一个具有Instant成员变量类型的 Java 类：

我正在使用 MongoTemplate 更新someInstant数据库中的字段：

如果我将该方法称为：

updateSomeRecordBySomeId("SOME-ID", Instant.now()); 将数据库中的字段作为Date类型持久保存： "someInstant" : ISODate("2017-07-11T07:26:44.269Z")

现在该方法也可以称为： updateSomeRecordBySomeId("SOME-ID", "2017-07-11T07:26:44.269Z");

在这种情况下，我得到一个例外：

org.springframework.core.convert.ConverterNotFoundException：找不到能够从类型 [java.lang.String] 转换为类型 [java.time.Instant] 的转换器

这是完全有道理的。（它就像更新数据库中的字段一样String。"someInstant" : "2017-07-11T07:26:44.269Z"）

MongoConfig.java：

StringToInstantConverter.java：

添加上述转换器后，我ConverterNotFoundException不再使用，但该字段someInstant被保留为纯字符串："someInstant" : "2017-07-11T07:26:44.269Z"

这就是我的问题。我知道转换器正在被识别，这就是我不再遇到异常的原因。但为什么转换器不转换String为Instant？为什么该领域被坚持为平原String？提供的转换器是否不正确？如何为这种情况编写转换器？

笔记：

• 我已经简化了代码以专注于实际问题。实际上，该方法不接收该someInstant字段作为参数。所以在这里编写重载方法将不适用。instanceOf此外，该方法内的任何类型的检查都不适用于实际情况。所以重点是为什么没有发生转换的问题？

• 对我们来说实际的数据存储是 DocumentDB，但是我们使用DocumentDB 和 MongoDB API（因为 Spring Data 不支持 DocumentDB）来进行数据库操作。

当 中存在LocalDateTime属性时Entity，在使用存储库接口查询以及单个数据源工作时，序列化失败。

当我只在 中使用以下配置时application.java，它不起作用：

当我不使用上面的配置时，LocalDateTime直接用下面的配置配置属性，就可以了：

谁能帮我？

注意：我在这里找到了一个与此相关的问题。

我正在尝试使用java.time类（JSR 310）的后端端口将对象转换为ZonedDateTime对象： ThreeTen-Backport项目。Calendar

我的理解是，后端端口应该类似于 Java 8 上的功能（而不是 Java 8 本身）。目前，该系统在 Java 7 上。

每当我尝试执行以下代码时：

我收到以下消息：

GregorianCalendar 类型的 from(ZonedDateTime) 方法未定义

我使用了以下依赖项：

怎么会出现这个问题？

任何帮助提示或建议将不胜感激。

TIA

我正在寻找一种解决方案来计算两个日期之间的月份。我认为 joda 或 java8 time 可以做到。但是当我比较它们时，我发现了一些非常奇怪的东西。

输出如下：

我对测试用例2感到很困惑，哪一个是合理的？

抱歉，这是我的第一个问题。附上完成的代码。

我正在为 REST 端点制作服务客户端，使用 JAX-RS 客户端处理 HTTP 请求，并使用 Jackson 来（反）序列化 JSON 实体。为了处理 JSR-310 (Java8) 日期/时间对象，我将com.fasterxml.jackson.datatype:jackson-datatype-jsr310模块作为依赖项添加到服务客户端，但我没有让它工作。

如何配置 JAX-RS 和/或 Jackson 以使用 jsr310 模块？

我使用以下依赖项：

我不想让服务客户端（作为库发布）依赖于任何特定的实现——比如 Jersey，所以我只依赖 JAX-RS API。为了运行我的集成测试，我添加了：

JAX-RS 客户端的实例化在工厂对象中完成，如下所示：

典型的 DTO 如下所示：

请求是这样完成的：

JSON 序列化和反序列化适用于字符串、整数、BigIntegers、列表等。但是，当我System.out.println(gateway.postSomthing(new Something("x", "y"));在测试中执行类似操作时，会出现以下异常：

从中我得出结论，杰克逊不知道如何将字符串反序列化为即时。我找到了关于这个主题的博客和 SO 问题，但我没有找到关于如何使其工作的明确解释。

请注意，我希望服务客户端能够处理"Fri, 22 Sep 2017 10:26:52 GMT"以及之类的日期字符串"2017-09-22T10:26:52.123Z"，但我希望它始终序列化为 ISO 8601 日期字符串。

谁能解释一下如何将反序列化变成Instant作品？

考虑这个使用 Spring Boot 启动的 Spring MVC 控制器：

我想用 Jackson JSR-310 模块序列化 Foo 对象。这种依赖关系在类路径上：

我的 application.properties 中也有杰克逊配置：

根据杰克逊文档，它应该将其转换为 ISO 日期时间格式，但我仍然得到一个时间戳值......

我注意到 ZonedDateTimeSerializer 内部：

useTimestamp(provider)被评估为true，因此 application.properties 中的属性被忽略。

有什么想法我的代码有什么问题吗？

问题：带有 Spring Data 返回日期的本机查询返回 java.sql.Date 而不是 java.time.LocalDate，尽管进行了设置。

上下文：一个带有 Spring Boot 2.0.0.M5（最新）、Hibernate 5.2.11、Hibernate-Java8 5.2.12（只要它在类路径上就支持 JSR310 类）的新项目。

下面的匿名示例（该应用程序与生日无关）：

在数据库（SQL Server）中，day 字段为 DATE，值类似于 2017-10-24。

问题是在运行时，Spring Data 存储库（我无法控制其实现，或者有办法？）没有返回java.sql.Datejava.time.LocalDate（澄清：返回类型似乎由 Spring Data 决定，java.sql.Date即使我将返回类型更改为be java.time.LocalDate，这就是我开始的方式）。

没有办法LocalDate直接获取吗？我可以稍后转换它，但是（1）效率低下，（2）存储库方法必须返回旧的日期/时间类，这是我想避免的。我阅读了 Spring Data文档，但对此一无所知。

编辑：对于任何有同样问题的人，下面是解决方案，Jens 建议的转换器。

我正在尝试始终如一地使用 Java 8 日期时间 API，我正在寻找这种行为背后的解释：

编译得很好，但产生：

我的问题是：如果这些类型不兼容，为什么 API 让我编写代码并编译它而不用尖叫？

我目前正在查看日期在英国夏令时内外时的 ZonedDateTime 行为。

英国夏令时从 3 月 25 日开始，增加一小时 (+1)。

我创建了几个 ZonedDateTime 实例（UTC 和欧洲/伦敦），接下来我添加了 1 个月，以便它们属于 ZonedDateTime。

这是我打印这些日期时的结果：

最后我打印出每个日期的纪元秒数：

我知道 ZonedDateTime 是不可变的。这意味着当我添加一个月时，我实际上创建了一个更改月份的新实例。您能否告诉我我对给定观察结果的假设是否正确：

1. 添加一个月将创建一个新的 ZonedDateTime 实例。ZonedDateTime 上的小时将始终相同。新日期是否在 BST 中并不重要。（查看 LondonFirstMarch 和 LondonFirstMarchPlusMonth）

2. 因为在添加 1 个月后 londonFirstMarchPlusMonth 落入 BST 以便它仍然是 12:00 它实际上已经提取了一个小时。这意味着基础纪元秒数将与 utcFirstMarchPlusMonth 不同。

3. 最后 londonFirstMarchPlusMonthToUtc 当我们将区域转换为 UTC 时，它显示实际时间是 11:00。

4. 如果我想要一个恰好在 1 个月后的日期。我应该只使用 UTC，最后可以选择将其转换为伦敦/欧洲吗？

编辑：

也许我不够清楚 - 道歉。一个月是任意值，因此当添加到第一个日期时，会产生属于 BST 的第二个日期。

如前所述，也许一个月不是一个很好的例子，因为它的含义取决于我们所处的月份。对我来说，重点是“月份”将由 24 小时单位组成。（正如 Ole.vv 所说）

我认为在 UTC 时间运行并可选择将其转换为欧洲/伦敦是“我的问题”的解决方案