为什么“12:00”是转换为 UTC 变为“11:00”?

发布于 2024-12-11 14:39:24 字数 738 浏览 1 评论 0 原文

我认为 2011-10-23 12:00:00 将与 UTC 保持相同,并且 转换日期 将是 <代码>2011-10-23 17:00:00

DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date dt = formatter.parse("2011-10-23 12:00:00");
LocalDateTime ldt = new DateTime(dt).withZone(DateTimeZone.UTC).toLocalDateTime();
LOGGER.warn("Original date: " + ldt.toDateTime().toDate().toString());
DateTime cvtldt = ldt.toDateTime(DateTimeZone.forID("-05:00"));
LOGGER.warn("Converted date: " + cvtldt.toLocalDateTime().toDateTime().toDate().toString());

我不明白为什么输出是负一小时?

Original date: Sun Oct 23 11:00:00 BST 2011
Converted date: Sun Oct 23 11:00:00 BST 2011    

I thought 2011-10-23 12:00:00 would remain the same as UTC and that the Converted date would be 2011-10-23 17:00:00.

DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date dt = formatter.parse("2011-10-23 12:00:00");
LocalDateTime ldt = new DateTime(dt).withZone(DateTimeZone.UTC).toLocalDateTime();
LOGGER.warn("Original date: " + ldt.toDateTime().toDate().toString());
DateTime cvtldt = ldt.toDateTime(DateTimeZone.forID("-05:00"));
LOGGER.warn("Converted date: " + cvtldt.toLocalDateTime().toDateTime().toDate().toString());

I don't understand why the output is minus one hour?

Original date: Sun Oct 23 11:00:00 BST 2011
Converted date: Sun Oct 23 11:00:00 BST 2011    

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

眉目亦如画i 2024-12-18 14:39:24

您正在使用 Date.toString(),它始终使用本地时区。看看你的字符串如何包含“BST”?

理想情况下,尽可能多地坚持 Joda 时间:

  • 使用 Joda 时间格式化程序进行解析
  • 不要转换回日期,除非您需要
  • >如果可以可能避免的话,就不要使用Date.toString();您无法控制其格式。

目前尚不清楚您真正想要实现的目标是什么,但几乎可以肯定您不想进行这么多转换。例如,您在调用 toLocalDateTime() 后再次调用 toDateTime() - 这意味着在您仔细指定 UTC 后,它正在使用系统默认时区之前的转换...

您的代码包含以下转换(按此顺序):

  • String to Date
  • Date to DateTime
  • DateTime to DateTime in UTC
  • DateTime to LocalDateTime (*)
  • LocalDateTime to DateTime
  • DateTime to Date
  • Date to String
  • (从结果中at *) LocalDateTime 到 DateTime
  • DateTime 到 LocalDateTime
  • LocalDateTime 到 DateTime
  • DateTime 到 Date
  • Date 到 String

您认为所有这些转换既必要又正确指定的可能性有多大? ;)

You're using Date.toString() which always uses the local time zone. See how your string contains "BST"?

Ideally, stick to just Joda Time for as much of the time as you can:

  • Parse with the Joda Time formatters
  • Don't convert back to Date unless you need to
  • Don't use Date.toString() if you can possibly avoid it; you have no control over its format.

It's not clear what you're really trying to achieve, but you almost certainly don't want to do this many conversions. For example, you're calling toLocalDateTime() followed by toDateTime() again - which means it's using the system default time zone, after you'd carefully specified UTC in the previous conversion...

Your code contains the following conversions (in this order):

  • String to Date
  • Date to DateTime
  • DateTime to DateTime in UTC
  • DateTime to LocalDateTime (*)
  • LocalDateTime to DateTime
  • DateTime to Date
  • Date to String
  • (From the results at *) LocalDateTime to DateTime
  • DateTime to LocalDateTime
  • LocalDateTime to DateTime
  • DateTime to Date
  • Date to String

What do you think the chances of all those conversions being both necessary and correctly specified are? ;)

旧故 2024-12-18 14:39:24

原始版本已更改,因为到 UTC 的转换是根据主机时区完成的,因此它应该更改。

转换后发生了变化,其实就是访问方式的问题。
您正在获取基准时间,并且修改器存储在其他字段中。

尝试进入调试模式,你会看到转换后的 cvtldt
具有带有修饰符的 toString。

问候,
格热西克

Original has changed because conversion to the UTC is done with respect to HOST time zone, so it should change.

Converted had changed, in fact it's the problem of accessing method.
You are getting base time and the modifier is stored in other field.

Try going into debugging mode and you will see that after conversion cvtldt
has toString with modifier.

Regards,
Grzesiek

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文