将带有日期和时间的字符串解析为特定的时间点（Java将其称为“ Instant”）非常复杂。Java已经通过多次迭代解决了这个问题。最新的java.time和java.time.chrono几乎可以满足所有需求（“ 时间膨胀”除外）。
但是，这种复杂性带来了很多混乱。
了解日期解析的关键是：
为什么Java有这么多种方式解析日期
- 有几种测量时间的系统。例如，日本的历史日历是从各个皇帝或王朝统治的时间范围得出的。然后是例如UNIX时间戳。幸运的是，整个（商业）世界都使用了相同的东西。
- 从历史上看，由于各种原因，系统之间会相互切换。例如从1582年的朱利安历法到公历。因此，在此之前的“西方”历法需要区别对待。
- 当然，更改不会立即发生。因为日历来自某些宗教的起源，而欧洲其他地区也相信其他饮食，例如德国直到1700年才转换。
......为什么是LocalDateTime，ZonedDateTime等人。这么复杂
有时区。时区基本上是地球表面的“条带” * [1]，其权限遵循何时具有哪个时间偏移的相同规则。这包括夏季时间规则。
时区会随着时间的变化而变化，这主要取决于谁征服谁。一个时区的规则也会随着时间而改变。
有时间偏移。这与时区不同，因为时区可能是“ Prague”（布拉格），但是具有夏令时和冬令时。
如果获得带时区的时间戳，则偏移量可能会有所不同，具体取决于所在的年份。在the年期间，时间戳可能表示2个不同的时间，因此如果没有其他信息，它就不可能可靠转换。
注意：通过时间戳记，我的意思是“包含日期和/或时间，以及时区和/或时间偏移的字符串。”
某些时区在某些时段可能共享相同的时间偏移。例如，当夏令时未生效时，GMT / UTC时区与“伦敦”时区相同。
使它更加复杂（但这对您的用例而言并不重要）：
- 科学家观察到地球的动力学随着时间的变化而变化。基于此，它们在各个年份的末尾增加了几秒钟。（因此
2040-12-31 24:00:00可能是有效的日期时间。）这需要定期更新元数据，系统使用这些元数据来进行日期转换。例如，在Linux上，您会定期更新Java软件包，包括这些新数据。
对于历史和将来的时间戳，更新并不总是保留以前的行为。因此，在不同版本的软件上运行时，围绕某个时区变化进行分析的两个时间戳进行比较可能会产生不同的结果。这也适用于在受影响的时区和其他时区之间进行比较。
如果这会导致软件错误，请考虑使用一些没有复杂规则的时间戳，例如UNIX timestamp。
由于7，对于将来的日期，我们无法完全确定地转换日期。因此，例如，当前的解析8524-02-17 12:00:00可能与将来的解析相差几秒钟。
JDK的API是随着现代需求而发展的
java.util.Date假设只有年，月，日和时间，那么早期的Java版本只是采用了一些幼稚的方法。很快这还不够。- 而且，数据库的需求是不同的，因此很早就
java.sql.Date引入了它，但它有其自身的局限性。
- 由于两者都没有很好地涵盖不同的日历和时区，
Calendar因此引入了API。
- 这仍然没有涵盖时区的复杂性。但是，上述API的混合使用确实很痛苦。因此，随着Java开发人员开始研究全球Web应用程序，针对大多数用例的库（如JodaTime）迅速受到欢迎。JodaTime是事实上的标准，已有大约十年的历史。
- 但是JDK没有与JodaTime集成，因此使用它有点麻烦。因此，在就如何解决此问题进行了很长时间的讨论之后，主要基于JodaTime创建了JSR-310。
如何在Java中处理 java.time
确定解析时间戳的类型
使用时间戳字符串时，需要知道它包含哪些信息。这是关键点。如果您做不到这一点，您将遇到一个神秘的异常，例如“无法创建即时”或“缺少区域偏移”或“未知区域ID”等。
是否包含日期和时间？
它有时间偏移吗？
时间偏移是其中的+hh:mm一部分。有时，+00:00可以用Z“祖鲁时间”，UTC“世界协调时间” 或GMT“格林威治标准时间” 代替。这些也设置了时区。
对于这些时间戳，请使用OffsetDateTime。
是否有时区？
对于这些时间戳，请使用ZonedDateTime。
区域由以下任一指定
- 名称（“布拉格”，“太平洋标准时间”，“太平洋标准时间”）或
- 由java.time.ZoneId表示的“区域ID”（“ America / Los_Angeles”，“欧洲/伦敦”）。
时区列表由ICAAN支持的“ TZ数据库”进行编译。
根据ZoneId的javadoc，区域ID也可以以某种方式指定为Z和偏移量。我不确定这是如何映射到真实区域的。如果仅具有TZ的时间戳落入时间偏移量变化的hour时间，则表示该模棱两可，并且解释以为主ResolverStyle，请参见下文。
如果两者都没有，则假定缺少的上下文或忽略该上下文。消费者必须决定。因此，需要通过添加缺少的信息将其解析为LocalDateTime并转换为OffsetDateTime：
- 您可以假设这是UTC时间。加上0小时的UTC偏移量。
- 您可以假设这是发生转换的时间。通过添加系统的时区进行转换。
- 您可以忽略并直接使用它。这很有用，例如比较或减去两次（请参阅参考资料
Duration），或者在您不知道且并不重要的时候（例如，本地公交车时刻表）。
部分时间信息
- 基于什么样的时间戳包含，你可以采取
LocalDate，LocalTime，OffsetTime，MonthDay，Year，或YearMonth出来。
如果您有完整的信息，则可以获取java.time.Instant。这在内部也用于在OffsetDateTime和之间进行转换ZonedDateTime。
弄清楚如何解析
有大量的文档DateTimeFormatter可以解析时间戳字符串和格式化为字符串。
在预先创建DateTimeFormatter小号应涵盖所有收起标准时间戳的格式。例如，ISO_INSTANT可以解析2011-12-03T10:15:30.123457Z。
如果您有某种特殊格式，则可以创建自己的DateTimeFormatter（它也是解析器）。
private static final DateTimeFormatter TIMESTAMP_PARSER = new DateTimeFormatterBuilder()
.parseCaseInsensitive()
.append(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SX"))
.toFormatter();
我建议您查看的源代码，DateTimeFormatter并获得有关如何使用进行构建的启发DateTimeFormatterBuilder。当您在那里时，还可以查看由ResolverStyle哪个控件控制解析器是格式，模糊信息还是LENIENT，SMART或STRICT。
时间访问器
现在，常见的错误是进入的复杂性TemporalAccessor。这来自于开发人员过去与之合作的方式SimpleDateFormatter.parse(String)。是的，DateTimeFormatter.parse("...")给你TemporalAccessor。
// No need for this!
TemporalAccessor ta = TIMESTAMP_PARSER.parse("2011-... etc");
但是，有了上一节的知识，您可以方便地解析为所需的类型：
OffsetDateTime myTimestamp = OffsetDateTime.parse("2011-12-03T10:15:30.123457Z", TIMESTAMP_PARSER);
您实际上并不需要DateTimeFormatter。您要解析的类型具有parse(String)方法。
OffsetDateTime myTimestamp = OffsetDateTime.parse("2011-12-03T10:15:30.123457Z");
关于TemporalAccessor，如果您对字符串中包含的信息有一个模糊的想法，并且想在运行时决定，则可以使用它。
我希望我对你的灵魂有所了解:)
注意：java.timeJava 6和7 有一个反向移植：ThreeTen-Backport。对于Android，它具有ThreeTenABP。
[1]不仅因为它们不是条纹，而且还有一些怪异的极端。例如，某些邻近的太平洋岛屿具有+14：00和-11：00时区。这就是说，在一个岛上，是5月1日下午3点，在另一个岛上，则是4月30日，下午12点（如果我算错了:)）
ZonedDateTime而不是LocalDateTime。这个名字是违反直觉的；这Local表示一般而言是任何地区，而不是特定的时区。这样，LocalDateTime对象就不会与时间轴相关。为了具有意义，要在时间线上获得指定的时刻，必须应用时区。