通过 JPA 加载 joda Instant 字段时时区错误
在我的 Play 应用程序中，我有一个模型，其中包含 created 类型为 Instant 的字段。它使用 @PrePersist 钩子进行填充，该钩子仅将其设置为 new Instant()。默认时区被正确检测为US/Chicago，并且当持久化到mysql时，它会出现在相同的时区中（在datetime字段中）。
但是，当从数据库读回对象并显示时间时，它会以 UTC 而不是本地时间显示。我目前正在使用
${org.joda.time.format.DateTimeFormat.forStyle("SS").printTo(out, object.created)}
Being new to Joda and相当新的JPA来显示它，我不确定这是一个joda问题，一个JPA问题，我是否应该使用不同的Joda类型，不同的mysql类型，或者如果我的想法是完全错误的。有人能指出我正确的方向吗？
In my Play application I have a model with a created field of type Instant. It's populated using a @PrePersist hook which just sets it to a new Instant(). The default timezone is correctly detected as US/Chicago, and when persisted to mysql it appears in the same timezone (in a datetime field).
However, when the object is read back from the database and the time is displayed, it's shown in UTC rather than local time. I'm currently displaying it using
${org.joda.time.format.DateTimeFormat.forStyle("SS").printTo(out, object.created)}
Being new to Joda and fairly new with JPA, I'm not sure if this is a joda problem, a JPA problem, if I should be using a different Joda type, a different mysql type, or if I'm going about this completely wrong. Can someone point me in the right direction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据 API UTC 似乎是参考时区。您随时可以在 DateTimeFormat 本身上更改它使用
withZone(DateTimeZone)方法。以下代码输出 America/Chicago 的日期，这似乎是 joda 中的正确的时区 -zime：按照用户指南，您还可以设置 joda 的默认时区：
DateTimeZone.setDefault(DateTimeZone.forID("America/Chicago"));但我一直认为使用 VM 参数指定默认时区也有效，并且应该是更好的选择。According to the API UTC seems to be the reference timezone. You can always change that on the DateTimeFormat itself with the
withZone(DateTimeZone)method. The following code outputs the date in America/Chicago which seems to be the right timezone in joda-zime:Following the user guide you can also set the default timezone for joda with
DateTimeZone.setDefault(DateTimeZone.forID("America/Chicago"));but I always thought that specifing the default timezone with an VM argument works too and should be the better option.