我正在使用java.sql.Date在我的一个域对象中存储日期字段。该字段映射到MySQL DATE列。当我尝试通过杰克逊将这个字段序列化为JSON时，杰克逊似乎没有考虑到夏令时。
以下是我的域对象中的字段：
@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd", timezone = "EST")
private Date date;
如您所见，杰克逊已被指示将时区解释为EST。我的MySQL数据库也在使用EST时区：
SHOW VARIABLES LIKE '%zone';
Output:
system_time_zone | EST
time_zone | SYSTEM
我的麻烦是，对于夏令时开始和结束之间的日期，杰克逊返回的日期少于存储在数据库中的日期。我假设这是因为杰克逊不考虑夏令时。
我通过尝试在Java字段中将日期的格式从yyyy-MM-dd更改为yyyy-MM-dd HH:mm:ss来得出这个结论。我注意到服务器返回了类似2017-03-13 00:00:00的东西，但杰克逊把它序列化为2017-03-12 23:00:00（减少一小时，这是夏令时影响的EST时间）。
有没有办法克服这个问题？另外，java.sql.Date是否使用正确的类型，考虑到它没有时间对应？我一直在考虑使用java.time.LocalDate，但我还没看到它是否会成功。
提前致谢！
java.sql.Date或java.util.Date。
仅使用java.time类。LocalDate。
您将只看到稳定的值，而不受夏令时（DST）的影响。例：
LocalDate.parse( "2019-01-23" )
java.sql.Date is not a date我不确定究竟是什么问题，但我怀疑这是由于你使用了可怕的java.sql.Date类，因此没有实际意义。
java.sql.Date类假装代表一个仅限日期的值，没有时间和没有时区。然而，由于一些难以想象的糟糕的设计决定，该类扩展了java.util.Date。 java.util.Date类确实有一个时间，并且是UTC。更令人困惑的是，java.util.Date在其源代码中隐藏了一个没有getter和setter的时区，所以它似乎还没有影响像equals这样的方法的行为。所以java.sql.Date，尽管它的名字，尽管其目的只是持有一个日期，实际上确实有一个时间设置为UTC。所以java.sql.Date在调整时间方面取得了一些特技，这可能是你遇到的问题。这些传统的日期时间类是一大堆...燕麦片。你永远不应该使用它们。
引用the JavaDoc为java.sql.Date类：
一个围绕毫秒值的瘦包装器，允许JDBC将其标识为SQL DATE值。毫秒值表示自1970年1月1日00：00：00.000 GMT以来经过的毫秒数。
为了符合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 is truly a date通过使用JSR 310和JDBC 4.2，您可以使用现代业界领先的java.time类。到目前为止，杰克逊可能已经更新为使用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，因此您的结果可能会有所不同。最好明确指定您期望/预期的时区作为参数。如果关键，请与您的用户确认该区域。
以proper time zone name的格式指定Continent/Region，例如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月的数字为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 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类？
ThreeTen-Extra项目使用其他类扩展了java.time。该项目是未来可能添加到java.time的试验场。你可能会在这里找到一些有用的类，如Interval，YearWeek，YearQuarter和more。