我正在使用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的内容，但杰克逊将其序列化为2017-03-12 23:00:00（少一小时，这是夏令时影响的EST时间）。
有什么办法可以解决这个问题？另外，考虑到java.sql.Date没有时间的对应性，它是正确使用的类型吗？我一直在考虑改用java.time.LocalDate，但还没有看到它是否会成功。
谢谢！
答案 0 :(得分：2)
java.sql.Date 或java.util.Date。LocalDate 。示例：
LocalDate.parse( "2019-01-23" )
java.sql.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在调整时间上有些st头，这很可能是您遇到的问题。这些传统的日期时间类是一大堆燕麦片。您永远不要使用它们。
要引用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继承，添加了 second 分数秒（纳秒）。也避免使用此类，现在将其替换为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 ) ;
LocalDate LocalDate类表示没有日期，没有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 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。