java解析的日期是未来几分钟

Question

我最近一直在对付一只讨厌的海森堡虫。这让我想起了famous 500-mile email story。我解析接收到的日期几乎是ISO 8601，但解析的Date对象有时是未来的几分钟。然而，当我试图在单元测试中解析相同的数据时，结果日期总是正确的

以下是我收到的格式：

2018-06-25T13:50:53.984771

我使用Jackson从JSON解析它：

new StdDateFormat().parse(timestamp);

以下是一些解析日期的示例：

2018-06-25T13:50:59.337828
Mon Jun 25 15:56:36 CEST 2018

2018-06-25T13:50:53.984771
Mon Jun 25 16:07:17 CEST 2018

两个小时的时差是可以的，这只是时区，但是分钟呢？它们似乎是随机偏移的

Answer 1

使用jackson-modules-java8和Basil Bourque在his answer中推荐的java.time类型。我没有使用jackson-modules-java8的经验，但它肯定能正确解析至少9位小数的秒分数，而且它确实支持现代日期时间类型

Answer 2

我在回答我自己的问题，希望有一天它能拯救别人的皮肤

这个问题没有在单元测试中表现出来，所以我认为服务器可能有问题。我尝试了所有我认为可能有问题的方法，包括研究被15分钟抵消的奇怪时区，调查Java实际从何处花费时间等等。最后，我别无选择，只能对代码进行几次修改，将可能出现的问题一分为二。结果是解析器

以下是导致问题的错误： https://github.com/FasterXML/jackson-databind/issues/1668

当一位朋友注意到时间戳末尾的毫秒数对应于以分钟为单位的偏移量时，我才找到它：

Original: 2018-06-25T13:50:53.984771
Milliseconds: 984771 ms = 16 minutes 24.77 seconds
Result: Mon Jun 25 16:07:17 CEST 2018

问题是，解析器将字符串的最后一部分计算为毫秒，并将它们悄悄地添加到内部Calendar对象，该对象愉快地接受任何毫秒数，并按设计将它们添加到自身中

这个问题没有在单元测试中表现出来的原因是，我创建的库使用了更新版本的Jackson，它不再包含这个bug。然而，使用该库的应用程序已经包含了Jackson，而且由于Maven在解析依赖项时选择了正在构建的库which is closest to the project的定义，因此它在库中用自己的^{中声明的旧版本覆盖了我的较新版本的Jackson。因此，最终这是一个自我施加的依赖地狱