我知道：
总的来说，对于大多数应用场景，这两种类型都可以使用。例如：我正在运行一个批处理作业，需要根据日期计算下一次运行时间，除了 Instant 具有纳秒精度和 LocalDateTime 具有时区部分之外，我很难找到这两种类型之间的优缺点。
你能列举一些只能使用 Instant 或者 LocalDateTime 的应用场景吗？
注：请注意关于精度和时区的问题，不要误读关于 LocalDateTime 的文档。
Instant 和 LocalDateTime 是两个完全不同的概念：一个代表一个时刻，而另一个则不是。
Instant 代表一个时刻，即时间轴上的一个具体点。LocalDateTime 代表一个日期和一天中的某个时间。但由于缺少时区或与UTC的偏移量，这个类无法表示一个时刻。它表示了一系列潜在的时刻，范围大约为全球所有时区的26到27小时。一个LocalDateTime 值是本质上含糊不清的。
LocalDateTime是包括人类时区的日期/时钟表示。
你的陈述是不正确的：LocalDateTime 没有时区。没有时区是该类的整个重点。
引用该类文档的话：
这个类并不存储或表示时区。相反，它是日期的描述，如生日，再加上墙上时钟所显示的当地时间。如果没有附加信息（例如偏移量或时区），它无法表示时间线上的瞬间。因此，Local... 意味着“未分区，无偏移量”。
Instant
Instant是一个时间线上的时刻，使用UTC计算，自1970年第一个UTC时刻的纪元以来的纳秒数（详细信息请参阅类文档）。由于大多数业务逻辑、数据存储和数据交换都应该使用UTC，因此这是一个经常使用的便捷类。
Instant instant = Instant.now() ; // Capture the current moment in UTC.
OffsetDateTime
类OffsetDateTime表示一个时刻，其日期和时间相对于UTC超前或落后一定的小时-分钟-秒数。偏移量，即小时-分钟-秒数由ZoneOffset类表示。
如果小时-分钟-秒数为零，则OffsetDateTime表示与Instant相同的UTC时刻。
ZoneOffset
ZoneOffset类表示与UTC相比提前或落后UTC的小时-分钟-秒数偏移量。
ZoneOffset仅仅是一个小时-分钟-秒数，没有更多的信息。而时区则包含名称和偏移量变化的历史记录。因此，使用时区总是优先于使用简单的偏移量。
ZoneId
例如，在巴黎，新的一天比在蒙特利尔早到来。因此，我们需要将时钟指针移动以更好地反映给定地区正午（太阳正好在头顶上的时间）。从欧洲西部/非洲向东/向西远离UTC线路越远，偏移量就越大。
时区是处理本地社区或地区实践的调整和异常规则集。最常见的异常情况是众所周知的疯狂行为夏令时(DST)。
时区具有过去规则、现在规则和未来近期确认规则的历史记录。
这些规则变化比您想象的要频繁。务必保持您的日期时间库的规则，通常是'tz'数据库的副本，处于最新状态。在Java 8中，通过Oracle发布时区更新工具更加容易保持最新。大陆/地区的格式指定正确的时区名称，例如America/Montreal、Africa/Casablanca或Pacific/Auckland。永远不要使用2-4个字母的缩写，如EST或IST，因为它们不是真正的时区，没有标准化，甚至不是唯一的(!)。
时区=偏移量+调整规则
ZoneId z = ZoneId.of( “Africa/Tunis” ) ;
ZonedDateTime
将ZonedDateTime概念上理解为具有指定ZoneId的Instant。
ZonedDateTime = ( Instant + ZoneId )
要捕捉特定区域（时区）人们使用的挂钟时间中看到的当前时刻：
ZonedDateTime zdt = ZonedDateTime.now( z ) ; // Pass a `ZoneId` object such as `ZoneId.of( "Europe/Paris" )`.
ZonedDateTime类和用于生成这些日期时间值的格式化程序类的目的。ZonedDateTime zdt = instant.atZone( z ) ;
String output = zdt.toString() ; // Standard ISO 8601 format.
DateTimeFormatter生成本地化格式的文本。DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL ).withLocale( Locale.CANADA_FRENCH ) ;
String outputFormatted = zdt.format( f ) ;
印度时间2019年4月30日23时22分55秒
LocalDate，LocalTime，LocalDateTime
LocalDateTime，LocalDate，LocalTime是一种不同的实体。它们不与任何特定地区或时区相关联，也不与时间线相关联。除非将它们应用于某个地区以找到时间线上的点，否则它们没有实际意义。Instant和ZonedDateTime类。LocalDateTime呢？有三种情况：
LocalDateTime。 在巴黎，午夜的时刻与蒙特利尔不同，与西雅图和奥克兰也不同。LocalDate ld = LocalDate.of( 2018 , Month.DECEMBER , 25 ) ;
LocalTime lt = LocalTime.MIN ; // 00:00:00
LocalDateTime ldt = LocalDateTime.of( ld , lt ) ; // Christmas morning anywhere.
LocalTime。为了真正有意义，您需要将其应用于时间轴，以确定斯图加特工厂或拉巴特工厂或悉尼工厂的下午12:30时刻。
另一种使用LocalDateTime的情况是预约未来事件（例如：牙医预约）。这些约会可能在将来足够遥远，以至于您面临政客重新定义时区的风险。政客通常很少提前警告，甚至没有任何警告。如果您的意思是“下一年1月23日下午3点”，无论政客如何改变时钟，您都不能记录一个时刻-如果该地区采用或取消夏令时，那么下午3点将变成下午2点或下午4点。
对于预约，存储LocalDateTime和ZoneId，分开保存。稍后，在生成时间表时，通过调用LocalDateTime::atZone( ZoneId )来动态确定一个时刻，并生成一个ZonedDateTime对象。
ZonedDateTime zdt = ldt.atZone( z ) ; // Given a date, a time-of-day, and a time zone, determine a moment, a point on the timeline.
Instant instant = zdt.toInstant() ; // Adjust from some zone to UTC. Same moment, same point on the timeline, different wall-clock time.
有些人可能会在时区或偏移量未知的情况下使用LocalDateTime。
我认为这种情况是不恰当和不明智的。如果有意但未确定时区或偏移量，则存在错误数据。这就像存储产品价格但不知道所用货币（美元、英镑、欧元等）。不是一个好主意。
为了完整起见，这里列出了Java中所有可能的现代和遗留日期时间类型，以及SQL标准定义的类型。这可能有助于将Instant和LocalDateTime类置于更大的上下文中。
Instant和ZonedDateTime。Instant。// Storing
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ;
myPreparedStatement.setObject( … , odt ) ;
// Retrieving
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
Instant instant = odt.toInstant() ;
转换ZonedDateTime。
// Storing
OffsetDateTime odt = zdt.toOffsetDateTime() ;
myPreparedStatement.setObject( … , odt ) ;
// Retrieving
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;
ZonedDateTime zdt = odt.atZone( z ) ;
java.time框架内置于Java 8及以上版本。这些类取代了老旧的传统日期时间类，如java.util.Date、Calendar和SimpleDateFormat。
你可以直接使用与JDBC 4.2或更高版本兼容的JDBC驱动程序，直接在数据库中交换java.time对象，无需字符串，无需java.sql.*类。Hibernate 5和JPA 2.2支持java.time。
如何获取java.time类？
ThreeTen-Extra项目通过添加额外的类来扩展java.time。该项目是java.time可能未来增加的类的试验场。您可能会在此处找到一些有用的类，例如Interval, YearWeek, YearQuarter和更多。
ZonedDateTime的含义。 - mkobitDateTime类名中添加了单词“Zoned”，以强调与“Local”类的区别（产生ZonedDateTime）。将名称“Local”视为“需要应用于某个特定地点”的简称。 - Basil Bourque一个主要的区别是LocalDateTime中的“本地”部分。如果你住在德国并创建了一个LocalDateTime实例，而其他人住在美国并在同一时刻创建了另一个实例（假设时钟设置正确），这些对象的值实际上会不同。但这不适用于Instant，它是独立于时区计算的。
LocalDateTime存储日期和时间，但不带时区，但其初始值是依赖于时区的。而Instant则没有。
此外，LocalDateTime提供了操纵日期组件（如天、小时和月份）的方法，而Instant则没有。
除了
Instant具有纳秒精度优势和LocalDateTime的时区部分之外
两个类具有相同的精度。 LocalDateTime不存储时区信息。请仔细阅读Javadocs文档，因为您可能会因此做出错误的假设：Instant 和 LocalDateTime。
LocalDateTime，你的理解是错误的：它不存储任何时区信息，且具有纳秒精度。引用Javadoc（重点在于强调）:
在 ISO-8601 日历系统中不带时区的日期时间，例如 2007-12-03T10:15:30。
LocalDateTime 是一个不可变的日期时间对象，表示日期时间，通常被视为年月日时分秒。可以访问其他日期和时间字段，例如年份中的天数、星期几和一年中的周数。时间以纳秒的精度表示。例如，“2007 年 10 月 2 日下午 13:45.30.123456789” 的值可以存储在 LocalDateTime 中。Instant 表示自 1970 年 01-01 的偏移量，因此代表时间线上特定的瞬间。在地球上两个不同地方同时创建的两个 Instant 对象将具有完全相同的值。Instant是格林威治时区的一个时间点。将其与用户的时区一起使用，以向他/她显示会议的开始时间，例如。
如果这两个类不表示您要存储/交换的内容，则可能ZonedDateTime或其他类可以更好地完成工作。
以下是一个简单的综合模式，可帮助您了解java.time包中的类及其与ISO-8601标准的关系，该标准用于可靠而轻松地在Java和其他语言或框架之间交换日期和时间：
java.time包的博客文章。java.time类的特点。一些类代表着绝对（或明确）的时间点（称为瞬间），而其他类如LocalDateTime只描述了所谓的挂钟时间。
LocalDateTime没有时区！ - Basil Bourque