5

我需要帮助。我一直试图弄清楚为什么 java util date 在从C#刻度转换后落后 5 小时。

在C#，日期是 6/8/2013 11:02:07 AM，我将此日期转换为刻度，然后将其作为long.

代码片段：

采取：

- long TICKS_AT_EPOCH = 621355968000000000L;
- long TICKS_PER_MILLISECOND = 10000;

java.util.Date date = new java.util.Date((ctime - TICKS_AT_EPOCH) / TICKS_PER_MILLISECOND);

现在 java util 日期是 Sat Jun 08 06:02:07 CDT 2013

请注意，小时是 5 小时的差异。

任何建议为什么？

4

4 回答 4

5

您正在构建自 1970 年 1 月 1java.util.Date日 UTC 以来的毫秒数。您似乎正在纠正.netSystem.DateTime.Ticks基于 1/1/0001 并且是 10,000 滴答声到一毫秒的事实。这是正确的，但您忘记了适应 UTC。

在 .Net 中，来自的值DateTime.Ticks高度依赖于DateTime.Kind属性。存在三种可能的DateTime值。

  • DateTimeKind.Utc- 这种表示该值代表UTC时间。它通常来自对 的调用DateTime.UtcNow，但也可以直接构造，而且通常是这样。例如，您可能正在从数据库中检索 UTC 时间。您可以将此处的刻度直接输入到您的转换中，它会起作用。

  • DateTimeKind.Local- 这通常来自对DateTime.Now. 这些值代表当地时区。在检查刻度之前，您需要转换为 UTC。您可以执行以下操作：

    DateTime dt = DateTime.Now;
int utcTicks = dt.ToUniversalTime().Ticks;

    请注意，如果时间发生在夏令时“回退”样式转换期间，则结果可能不正确。DateTime班级不知道时区。它只是反映当前的本地时钟。如果 in 的值dt不明确，ToUniversalTime()将假定该值代表标准时间，即使您只是在白天检索它。这只是DateTime.net 中许多令人困惑和可能的方面之一。

  • DateTimeKind.Unspecified- 这是DateTime您会遇到的最常见的类型，通常来自DateTime.Parse()或类似new DateTime(...). 不幸的是，这里没有任何内容可以告诉您这些日期所代表的时区。您仍然可以尝试调用.ToUniversalTime()，但框架会假设这些时间代表您当地的时区，就好像那种时间是Local. 该假设可能完全错误，具体取决于您获取数据的方式。确实没有将 anUnspecified DateTime转换为 UTC 值（刻度或其他）的安全方法。

有一些解决方案，例如使用DateTimeOffset代替DateTime，或使用Noda Time库代替内置类型。您可以在此处和此处阅读有关这些问题的更多信息。

于 2013-06-23T23:18:05.407 回答
1

时间不是晚了5个小时，而是完全相同的时间。问题在于您的打印方式。

在将日期转换为字符串时，您需要告诉 C# 和 Java 使用相同的时区。其中一个是使用 UTC，另一个是 CDT。

于 2013-06-23T05:33:50.900 回答
0

java.util.date 自动更正您的时区。看到这个问题：How to set time zone of a java.util.Date?

于 2013-06-23T05:31:25.413 回答
0

是ctimeUTC（通用协调时间），它是参考格林威治的时间标准。你用中央时间表达你的时间。有你的不同。

于 2013-06-23T05:32:40.610 回答