Why does java.time.Clock has zone information? From the Clock you only can get an Instant when calling the instant() method - which is a time without zone info.

Is the only purpose to have the zone available in the clock to e.g. create a ZonedDateTime like this? ZonedDateTime.ofInstant(clock().instant(), clock().getZone())

Wouldn't it then make sense to have a method zonedDateTime() in the Clock class?

我在 Spring Boot (2.1.2) 系统中重构了一些遗留代码并从java.util.Date基于java.time类 (jsr310) 迁移。系统需要 ISO8601 格式字符串中的日期，而有些是带有时间信息的完整时间戳（例如"2019-01-29T15:29:34+01:00"），而其他只是带有偏移量的日期（例如"2019-01-29+01:00"）。这是 DTO（作为 Kotlin 数据类）：

虽然杰克逊完美反序列化processingTimestamp，但它失败了orderDate：

这对我来说很有意义，因为OffsetDateTime找不到构建瞬间所需的任何时间信息。如果我更改为val orderDate: LocalDateJackson 可以成功反序列化，但是偏移信息消失了（我需要Instant稍后转换）。

问题

我目前的解决方法是OffsetDateTime结合使用自定义反序列化器（见下文）。但我想知道，是否有更好的解决方案？

另外，我希望有一个更合适的数据类型，比如OffsetDate，但我在java.time.

附言

我在问自己“2019-01-29+01:00”是否对 ISO8601 有效。但是，由于我发现它java.time.DateTimeFormatter.ISO_DATE可以正确解析它并且我无法更改客户端发送数据的格式，所以我搁置了这个问题。

解决方法

我想将 a 序列化为LocalDateTime文本格式，同时只显示毫秒。我尝试了以下示例：

这输出：

所以精度仍然以纳秒为单位，尽管没有按照mapper.disable(SerializationFeature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS).

我期望：

为什么是这样？我怎样才能解决这个问题？

根据这里的描述，我应该ZonedDateTime使用 JSR-310 表示而不是数字表示来序列化对象。但是，我得到了数字表示。可能是什么问题呢？

这就是我配置我正在使用的映射器的方式：

这是我得到的反序列化示例

对于以下案例类：

（从CodeReview迁移而来）

我正在试验并试图更好地理解 Java Time。我的代码没有按预期工作，我想问一下原因，可能是因为我对 JSR-310 时区处理存在误解。

我有一个时间戳字符串来解析DateTimeFormatter

上面的值是在服务器的本地时间是中欧上午 10:39 时生成的。由于夏令时区，UTC 时间是早上 8:39。您可以自己计算一下您所在区域的时间。

当计算机的时区与时间戳（+2）中显示的时区相同时，以下测试有效

我试图修改输入字符串以更好地理解 Java Time 如何调整时区。但结果出乎意料的错误！

我试图反复更改输入字符串中的时区，以使测试失败。例如，如果我将字符串更改为2019-08-28T10:39:57+08:00它意味着它是巴黎的凌晨 2 点。但是在检查一天中的时间时，上面的测试代码继续通过。即导致LocalDateTime一天中的时间仍然是上午 10 点。

问题

为什么我的代码仍然返回 10 作为一天中的本地时间，而不管我在源字符串中不断更改其时区这一事实？

那么解析 RFC 3339 字符串（表示嵌入偏移中的瞬间）并将其转换LocalDateTime为可能的区域调整对象的正确方法是什么？假设机器在 CE[S]T 时区运行。

环境

我需要将时间戳与计算机时间进行比较，并检查它是否不太旧。这意味着如果在欧洲评估美国时间，它可能不会“太旧”。

我正在使用 jooq (v3.11.9) 访问在 UTC 时间运行的 MySQL 数据库。我使用生成的实体并且正在使用 JSR-310 时间类型。我在配置中使用的选项：

我的理解是 MySQLdatetime和timestamp类型都映射到LocalDateTime这很有意义，因为 MySQL 不会随时间存储时区信息。但是，当我在不同时区（在我的情况下为 EST）的机器上运行查询时，日期都在我的本地机器时区，即使会话时区是 UTC。

我已经确认会话时区是 UTC

返回

时区转换示例：

我生成的实体中的字段：

所以我的问题是：

1. 这是预期的行为吗？不应该用表中的原始（非时区）日期填充记录。由于某种原因，日期是否仍在后台转换为 java.sql.Timestamp？

2. 如果这是预期的行为，是否有任何方法可以确保您在会话时区中获取日期，而不管客户端计算机上的本地时区如何？如果代码的行为取决于机器时区，则很难在本地进行测试。

预先感谢您的帮助。

我处于从 type 转换为 type 的场景A中B。TypeA有一个 date 字段，它是 type YearMonth，而 typeB的 date 字段是 a String。我不想重新发明轮子，所以如果我可以使用 Jackson DataType JSR310 库进行此转换，那就太好了。

但是，我很困惑如何以独立的方式使用YearMonthSerializer's publicserialize方法；YearMonthDeserializer的公共deserialize方法也是如此。

serialize接受 a YearMonth(fine) 旁边的 a JsonGeneratorand SerializationProvider(what?) 我不知道如何检索它，而derialize甚至没有 aString作为参数，只有 a JsonParserand DeserializationContext。

我不想以典型的方式使用这个库，@JsonSerialize(using = YearMonthSerializer.class)因为我没有将整个 POJO 转换为 JSON 字符串，只是将一个YearMonth字段转换为String.

基于这些 API，尽管看起来我绝对不打算以这种期望的方式使用该库。

这是 javadoc 的链接。

我有以下测试。

我试图解析的日期时间之间的唯一区别是，在第一种情况下，时区指定的小时和分钟之间没有冒号，而在第二种情况下，有一个冒号。

首先他们失败了：

根据 javadoc，parse(), through DateTimeFormatter.ISO_ZONED_DATE_TIME, 最终使用DateTimeFormatter.ISO_OFFSET_DATE_TIME, 反过来，我们可以读到它是

ISO 日期时间格式化程序，用于格式化或解析带有偏移量的日期时间，例如“2011-12-03T10:15:30+01:00”。

进一步遵循 javadoc 链接，我们得到ZoneOffset.getId()它接受的内容：

因此，根据 javadocs，冒号始终是强制性的。

但是，根据https://en.wikipedia.org/wiki/ISO_8601，

UTC 偏移以与上面的“Z”相同的方式附加到时间，格式为 ±[hh]:[mm]、±[hh][mm] 或 ±[hh]。

因此，根据标准，冒号不是强制性的，Java 似乎并不完全支持该标准。

问题是：为什么？遗漏是故意的吗，这有充分的理由吗？

这在 Java 8 和 Java 11 中都以这种方式工作。

我试图"2020-01-12+01:00"用 JSR-310 时间来解析让我们说。

我通过 阅读它DateTimeFormatter.ofPattern("yyyy-MM-ddVV")，但是现在如果我想将其转换为 Instant via Instant.from(DateTimeFormatter.ofPattern("yyyy-MM-ddVV").parse("...")，它会抛出它抱怨time为空的地方。

确实如此，但是，我想从中获得 Instant，即 epochMillis，因此我可以将其序列化long到数据库中。

有办法解决吗？基本上我想像往常一样扩展"2020-01-12+01:00"to"2020-01-12T00:00.000+01:00"并将其解析为 Instant

我有一个要求，如果 ISO 日期时间没有指定区域偏移量，我应该假设欧洲/布拉迪斯拉发的当前偏移量。

基本上"2020-03-26T22:47:32.497" -> "2020-03-26T22:47:32.497+01:00"

特长; 如果有，则解析时区ID，但如果不存在，则默认为特定的

我现在拥有的

显然它不起作用。甚至可能吗？我应该只有 2 个格式化程序（一个有 tz，一个没有）然后一个接一个地尝试吗？