Spring 中的 @DateTimeFormat 会产生相差一天的错误
我目前在域对象中使用@DateTimeFormat，如下所示：
@DateTimeFormat(pattern = "MM/dd/yyyy")
private Date startDate = new Date();
在 Spring MVC 控制器中，我使用 jQuery UI 日期选择器发布今天的日期：10/19/2011，并且我确认这是作为 HTTP Post 参数发送的使用 firebug 如下：
startDate=10%2F19%2F2011
不幸的是，一旦到达服务器上的 Spring，它将日期存储为 10/18/2011 - 存在相差一天的错误。
我的代码中没有任何内容甚至远程触及日期 - 没有与该日期相关的计算或任何事情。
关于 @DateTimeFormat 有什么我应该注意的吗？
Hibernate 中的某些东西也可以负责更改日期吗？
我还在查看此应用程序的数据库。我正在存储另一个日期，称为creationDate，它是一个实际的时间戳，与用户输入不同。在大多数情况下，日期是相同的，但客户希望能够以不同的方式设置它，这就是 startDate 的用途。
Start Date Creation Date (actual timestamp, not user input)
2011-04-17 19:00:00 2011-04-17 21:32:27
2011-04-18 19:00:00 2011-04-18 21:14:01
2011-04-20 19:00:00 2011-04-20 23:06:47
2011-04-26 19:00:00 2011-04-26 23:24:34
2011-04-28 19:00:00 2011-04-28 20:07:06
2011-05-01 19:00:00 2011-05-02 13:35:37
2011-06-21 19:00:00 2011-06-22 15:06:36
2011-07-28 19:00:00 2011-07-29 15:32:35
2011-09-03 19:00:00 2011-09-04 13:11:45
2011-10-11 19:00:00 2011-10-12 11:45:14
2011-10-11 19:00:00 2011-10-12 11:49:55
2011-10-18 19:00:00 2011-10-19 02:20:43
起初，这似乎是 5 月份开始的错误，但后来我意识到，如果日期超过 19:00:00，则日期是正确的；如果日期低于 19:00:00，则日期会相差 1。
我讨厌 Java :(
当 Spring 创建给定的日期 10/19/2011 时，似乎会出现问题 - 它似乎会转换用户输入并将其格式化为 2011-10-18 19： 00:00
的解决方案是什么？
最简单
I am currently using @DateTimeFormat in a domain object as follows:
@DateTimeFormat(pattern = "MM/dd/yyyy")
private Date startDate = new Date();
In a Spring MVC Controller, I am posting today's date: 10/19/2011 using the jQuery UI Date picker, and I confirm that this is being sent as an HTTP Post parameter using firebug as follows:
startDate=10%2F19%2F2011
Unfortunately, once it gets to Spring on the server, it stores the date as 10/18/2011 - there is an off-by-one day error.
There is nothing in my code that even remotely touches the date - there is no calculations or anything going on with regards to this date.
Is there something about @DateTimeFormat that I should be aware of?
Could something in Hibernate be responsible for changing the date too?
I'm also looking at the my database for this application. I am storing another date, called creationDate which is an actual timestamp and differs from user input. In most cases, the dates are the same but the client wanted the ability to set it differently so that is what startDate is for.
Start Date Creation Date (actual timestamp, not user input)
2011-04-17 19:00:00 2011-04-17 21:32:27
2011-04-18 19:00:00 2011-04-18 21:14:01
2011-04-20 19:00:00 2011-04-20 23:06:47
2011-04-26 19:00:00 2011-04-26 23:24:34
2011-04-28 19:00:00 2011-04-28 20:07:06
2011-05-01 19:00:00 2011-05-02 13:35:37
2011-06-21 19:00:00 2011-06-22 15:06:36
2011-07-28 19:00:00 2011-07-29 15:32:35
2011-09-03 19:00:00 2011-09-04 13:11:45
2011-10-11 19:00:00 2011-10-12 11:45:14
2011-10-11 19:00:00 2011-10-12 11:49:55
2011-10-18 19:00:00 2011-10-19 02:20:43
At first it seems like it was a bug started in May, but then I realized that the date is correct if it was over 19:00:00, and it's off-by-one if it's under 19:00:00.
I hate Java :(
The problem seems to occur when Spring creates a date given 10/19/2011 - it seems to translate that user input and formats it to 2011-10-18 19:00:00.
What is the simplest solution?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，这很可能实际上是一个时区问题。
Date对象代表时间上的瞬间 - 我怀疑如果您查看所获得的确切值（例如，以 UTC 表示，以保持清晰），您会更好地了解正在发生的事情。当您看到“10/18/2011”时，您很可能会在不同的时区解释它。如果 Spring 支持转换为 Joda Time 类型，我建议使用它 - 那么你可以使用
LocalDate实际上确实表示日期而不是即时时间。It seems very likely to me that this is actually a matter of time zones. A
Dateobject represents an instant in time - I suspect if you look at the exact value that you've got (e.g. in UTC, to keep things clear) you'll get a better idea of what's going on. Chances are that where you're seeing "10/18/2011" you're interpreting it in a different time zone.If Spring supports converting to Joda Time types I'd suggest using that instead - then you can use
LocalDatewhich really does mean a date instead of an instant in time.我发现使用参数中指定的本地时区启动 JVM 可以解决此问题。对我来说，只需将这一行添加到运行配置中：
I've found that starting your JVM with your local timezone specified in the arguments solves this issue. For me it was just adding this line to the run configuration: