java.util.Date正在分析日期早于1912年的错误日期

我不明白为什么杰克逊图书馆在1912年之前解析错误的日期。我认为问题在于java.util.Date转换，因为Gson仍然存在这个问题

这是我的代码：

ObjectMapper mapper = new ObjectMapper();
String tmp = "{\"date\":\"1911-01-01T00:00:00+00:00\"}";
        
Response resp = mapper.readValue(tmp, Response.class);
System.out.println("Date->"+resp.date);

date是java.util.date类型的字段

如您所见，输入为：1911-01-01T00:00:00+00:00

输出是：Sun Jan 01 00:09:21 CET 1911我不明白为什么要设置这个时间

但是如果我设置这个输入：1912-01-01T00:00:00+00:00

输出正确：周一1月1日00:00:00 CET 1912

只在1912年之前发生

Jdk v1.8.0_101

谢谢。

java.time 永远不要使用旧类日期。不要浪费时间去理解日期和日历的混乱

仅使用现代java.time类。Jackson的更高版本支持java.time

当要求生成表示其值的文本时，OffsetDateTime生成：

odt.toString:1911-01-01T00:00Z

末尾的Z表示与UTC的偏移量为零小时分秒，发音为“Zulu”

有关使用遗留类的代码发生了什么的解释，请参见，但请注意，在java.time中使用正确设计的类可以避免根本的问题：应用不需要调用的时区

时区是特定地区人民使用的偏移量的过去、现在和未来变化的历史。输入的偏移量为零，没有时区指示。因此，在处理输入时不需要涉及时区。

java.time 永远不要使用旧类日期。不要浪费时间去理解日期和日历的混乱

仅使用现代java.time类。Jackson的更高版本支持java.time

当要求生成表示其值的文本时，OffsetDateTime生成：

odt.toString:1911-01-01T00:00Z

末尾的Z表示与UTC的偏移量为零小时分秒，发音为“Zulu”

有关使用遗留类的代码发生了什么的解释，请参见，但请注意，在java.time中使用正确设计的类可以避免根本的问题：应用不需要调用的时区

---

时区是特定地区人民使用的偏移量的过去、现在和未来变化的历史。输入的偏移量为零，没有时区指示。因此，在处理您的输入时，无需涉及时区。

巴兹尔•布尔克（Basil Bourque）已经发布了一份包含好的解决方案的好答案。下面的答案解释了你观察到的原因

欧洲/巴黎时区从定义标准时间到1911年3月11日的偏移量为+00:09:21。我相信法国在北非的一些属地阿尔及利亚、突尼斯也效仿了。因此，如果您的默认时区位于其中一个位置，那么VGR在您的输出正确的注释中是正确的

吹毛求疵：只有时区缩写值得商榷。根据下面的链接，应该是巴黎平均时间的PMT，而不是中欧时间的CET。我不认为现在过时的Date类曾经有过给出正确的历史时区缩写的野心。它可能只是给出CET，因为现在巴黎使用中欧时间

曾几何时，每个首都和许多其他大都市的时间都是由平均太阳时来定义的，而不是由标准时间的整小时数来定义的——GMT后来获得了这个角色，UTC后来也获得了这个角色。所以+00:09:21的偏移量在当时没有什么特别的

    ZonedDateTime dateTimeInFrance = OffsetDateTime.parse("1911-01-01T00:00:00+00:00")
            .atZoneSameInstant(ZoneId.of("Europe/Paris"));
    System.out.println(dateTimeInFrance);

输出：

1911-01-01T00:09:21+00:09:21[欧洲/巴黎]

近似重复：

---

进一步链接：

巴兹尔•布尔克已经发布了一个很好的答案和很好的解决方案。下面的答案解释了你观察到的原因

欧洲/巴黎时区从定义标准时间到1911年3月11日的偏移量为+00:09:21。我相信法国在北非的一些属地阿尔及利亚、突尼斯也效仿了。因此，如果您的默认时区位于其中一个位置，那么VGR在您的输出正确的注释中是正确的

吹毛求疵：只有时区缩写值得商榷。根据下面的链接，应该是巴黎平均时间的PMT，而不是中欧时间的CET。我不认为现在过时的Date类曾经有过给出正确的历史时区缩写的野心。它可能只是给出CET，因为现在巴黎使用中欧时间

曾几何时，每个首都和许多其他大都市的时间都是由平均太阳时来定义的，而不是由标准时间的整小时数来定义的——GMT后来获得了这个角色，UTC后来也获得了这个角色。所以偏移量为+0 0:09:21那时候没什么特别的

    ZonedDateTime dateTimeInFrance = OffsetDateTime.parse("1911-01-01T00:00:00+00:00")
            .atZoneSameInstant(ZoneId.of("Europe/Paris"));
    System.out.println(dateTimeInFrance);

输出：

1911-01-01T00:09:21+00:09:21[欧洲/巴黎]

近似重复：

---

进一步链接：

我不打算花时间调查这件事，因为正如Basil Bourque的回答所说，您应该切换到java.time包，而不是使用遗留的java.util.Date类-但是-我想问题是java.util.Date转换-作为一般规则，您不应该假设错误出现在一个完善的库或包中；这几乎总是软件包用户的误解或错误。在彻底调查自己的代码之前，不要责怪软件包。1912年是民国历法中一个重要的日子，也是明治时代的结束，所以可以考虑到这一点。你的默认时区是哪一个？欧洲/马德里？欧洲/巴黎？还有什么？输出是正确的。过去有一些奇怪的时区变化。我知道有一个现有的堆栈溢出问题涉及到这一点…可能与此相关：我不打算花时间调查这个问题，因为正如Basil Bourque的回答所说，您应该切换到java.time包，而不是使用遗留的java.util.Date类-但是-我想问题是java.util.Date转换-作为一般规则，您不应该假设错误出现在一个完善的库或包中；这几乎总是软件包用户的误解或错误。在彻底调查自己的代码之前，不要责怪软件包。1912年是民国历法中一个重要的日子，也是明治时代的结束，所以可以考虑到这一点。你的默认时区是哪一个？欧洲/马德里？欧洲/巴黎？还有什么？输出是正确的。过去有一些奇怪的时区变化。我知道有一个现有的堆栈溢出问题涉及到这一点……可能与此相关：好的建议。但这会产生什么样的结果呢？它解决了问题吗？@ErwinBolwidt在OffsetDateTime上调用toString生成的文本与输入几乎相同。没有不必要的时区，问题解决了。很好的建议。但这会产生什么样的结果呢？它解决了问题吗？@ErwinBolwidt在OffsetDateTime上调用toString生成的文本与输入几乎相同。没有不必要的时区，问题解决了。