我正在使用java.sql.Date将日期字段存储在我的一个域对象中。该字段映射到MySQL DATE列。当我尝试通过杰克逊将该字段序列化为JSON时，杰克逊似乎并未考虑夏令时。
这是域对象在我的域对象中的样子：
@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd", timezone = "EST")
private Date date;
如您所见，Jackson被指示将时区解释为EST。我的MySQL数据库也使用EST时区：
SHOW VARIABLES LIKE '%zone';
Output:
system_time_zone | EST
time_zone | SYSTEM
我的麻烦是，对于夏令时开始和结束之间的日期，Jackson返回的日期比数据库中存储的日期少一天。我认为这是因为杰克逊没有考虑夏令时。
我通过尝试在Java字段中将日期的格式从
yyyy-MM-dd更改为yyyy-MM-dd HH:mm:ss得出了这个结论。我注意到服务器返回了类似2017-03-13 00:00:00的内容，但是Jackson将其序列化为2017-03-12 23:00:00（少一小时，这是夏令时影响的EST时间）。有什么办法可以克服这个问题？另外，考虑到
java.sql.Date没有对应的时间，它是正确使用的类型吗？我一直在考虑使用java.time.LocalDate代替，但是我还没有看到它是否会成功。提前致谢！
最佳答案
tl; dr
切勿使用java.sql.Date或java.util.Date。仅使用java.time类。
对于仅日期的值，请使用LocalDate。您只会看到稳定的值，而不受夏令时（DST）的影响。
例：
LocalDate.parse( "2019-01-23" )
java.sql.Date不是日期我不确定问题到底出在哪里，但是我怀疑这是由于您使用了可怕的
java.sql.Date类，因此引起了争议。java.sql.Date类假装代表仅日期的值，没有日期时间和时区。但是，由于一些不可思议的错误设计决策，该类扩展了java.util.Date。 java.util.Date类确实有一天中的某个时间，并且采用UTC。更令人困惑的是，java.util.Date在其源代码中隐藏了一个时区，没有getters和setters，因此似乎尚不影响equals之类的方法的行为。因此，尽管java.sql.Date具有名称，并且具有仅保留日期的目的，但实际上确实将时间设置为UTC。因此，java.sql.Date在调整一天中的时间时会遇到一些困难，这很可能是您遇到的问题。这些传统的日期时间类是一大堆燕麦片。您永远不要使用它们。引用
java.sql.Date类的the JavaDoc：毫秒值左右的精简包装，可让JDBC将其标识为SQL DATE值。毫秒值表示自格林尼治标准时间1970年1月1日00：00：00.000起经过的毫秒数。
为了符合SQL DATE的定义，必须通过将与实例相关联的特定时区中的小时，分钟，秒和毫秒设置为零，来“标准化” java.sql.Date实例包装的毫秒值。 。
顺便说一句，
java.sql.Timestamp一样糟糕。它也很笨拙地从java.util.Date继承，添加了第二个小数秒（纳秒）。也避免使用此类，现在用java.time.Instant或java.time.OffsetDateTime代替。同样，java.sql.Time被替换为java.time.LocalTime。java.time.LocalDate是真正的约会通过采用JSR 310和JDBC 4.2，您可以使用现代业界领先的java.time类。到目前为止，Jackson可能已更新为使用java.time。如果不是，请参见this Question以获取指向用于在Jackson中处理java.time的数据类型模块的链接。
看起来您的输入字符串采用标准ISO 8601格式，即YYYY-MM-DD。解析/生成表示日期时间值的字符串时，默认情况下，java.time类使用标准格式。对于仅用于日期的用途，
LocalDate类实际上是没有日期且没有区域/偏移的日期。您将看到稳定的日期值，而不受Daylight Saving Time (DST)的影响。解析。
LocalDate ld = LocalDate.parse( "2019-01-23" ) ;
商店。
myPreparedStatement.setObject( … , ld ) ;
检索。
LocalDate ld = myResultSet.getObject( … , LocalDate.class ) ;
关于
LocalDateLocalDate类表示没有日期，没有time zone或offset-from-UTC的仅日期值。时区对于确定日期至关重要。在任何给定时刻，日期都会在全球范围内变化。例如，在Paris France中午夜之后的几分钟是新的一天，而在Montréal Québec中仍是“昨天”。
如果未指定时区，则JVM隐式应用其当前的默认时区。该默认值可能会在运行时（！）期间change at any moment，因此您的结果可能会有所不同。最好将您的期望/期望时区明确指定为参数。如果紧急，请与您的用户确认区域。
以
Continent/Region的格式指定proper time zone name，例如America/Montreal，Africa/Casablanca或Pacific/Auckland。切勿使用2-4个字母的缩写，例如EST或IST，因为它们不是真实的时区，不是标准化的，甚至不是唯一的（！）。ZoneId z = ZoneId.of( "America/Montreal" ) ;
LocalDate today = LocalDate.now( z ) ;
如果要使用JVM的当前默认时区，请提出要求并作为参数传递。如果省略，代码将变得难以理解，因为我们不确定您是否打算使用默认值，还是像许多程序员一样不知道该问题。
ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone.
或指定一个日期。您可以用数字设置月份，一月至十二月的理智编号为1-12。
LocalDate ld = LocalDate.of( 1986 , 2 , 23 ) ; // Years use sane direct numbering (1986 means year 1986). Months use sane numbering, 1-12 for January-December.
或者，最好使用预定义的
Month枚举对象，一年中的每个月使用一个。提示：在整个代码库中使用这些Month对象，而不仅仅是一个整数，可以使您的代码更具自记录性，确保有效值并提供type-safety。 Year和YearMonth的同上。LocalDate ld = LocalDate.of( 1986 , Month.FEBRUARY , 23 ) ;
关于java.time
java.time框架内置于Java 8及更高版本中。这些类取代了麻烦的旧legacy日期时间类，例如
java.util.Date，Calendar和SimpleDateFormat。要了解更多信息，请参见Oracle Tutorial。并在Stack Overflow中搜索许多示例和说明。规格为JSR 310。
现在位于Joda-Time中的maintenance mode项目建议迁移到java.time类。
您可以直接与数据库交换java.time对象。使用与JDBC driver或更高版本兼容的JDBC 4.2。不需要字符串，不需要
java.sql.*类。在哪里获取java.time类？
Java SE 8，Java SE 9，Java SE 10，Java SE 11和更高版本-具有捆绑实现的标准Java API的一部分。
Java 9添加了一些次要功能和修复。
Java SE 6和Java SE 7
大多数java.time功能都被反向移植到ThreeTen-Backport中的Java 6和7。
Android
更高版本的Android捆绑了java.time类的实现。
对于较早的Android（ThreeTenABP项目改编为ThreeTen-Backport（如上所述）。请参见How to use ThreeTenABP…。
ThreeTen-Extra项目使用其他类扩展了java.time。该项目是将来可能向java.time添加内容的试验场。您可能会在这里找到一些有用的类，例如
Interval，YearWeek，YearQuarter和more。