Question

我需要帮助。我一直试图弄清楚为什么从C#刻度转换后，java实用日期落后了5个小时。

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

代码段：

采取：

- 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实用日期是星期六08 06:02:07 CDT 2013

请注意，小时差异为5小时。

有什么建议吗？

Answer 1

您正在根据自1970年1月1日UTC以来的毫秒构建java.util.Date。您似乎正在纠正.net的System.DateTime.Ticks基于1/1/0001并且10,000个刻度到1毫秒的事实。这是正确的，但您忘记调整为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班级不了解时区。它只反映了当前的本地时钟。如果dt中的值不明确，ToUniversalTime()将假定该值代表标准时间，即使您在白天时间内检索到它 EM>。这只是.net中DateTime的许多令人困惑和可能的方面之一。
DateTimeKind.Unspecified - 这是您遇到的最常见的DateTime种类，通常来自DateTime.Parse()或new DateTime(...)等构造函数。很遗憾，这里没有任何内容可以告诉您这些日期代表的时区。您仍然可以尝试拨打.ToUniversalTime()，但框架会假设这些时间代表您当地的时区，就好像那种Local一样。这种假设可能完全错误，具体取决于您采购数据的方式。确实没有安全的方法可以将Unspecified DateTime转换为UTC值（滴答或其他）。

有一些解决方案，例如使用DateTimeOffset代替DateTime，或使用Noda Time库而不是内置类型。您可以详细了解这些问题here和here。

Answer 2

时间不落后5个小时，这是完全相同的时间。问题在于打印方式。

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

Answer 3

java.util.date会自动更正您的时区。请参阅此问题：How to set time zone of a java.util.Date?

Answer 4

ctime是UTC（通用协调时间），这是参考格林威治的时间标准。你在中部时间表达你的时间。这是你的不同。

C＃Ticks转换为java util date;日期落后5小时？

4 个答案: