C#Ticks转换为java util date；日期比原因晚了5个小时

本文关键字：小时 5个 日期 转换 java util date C#Ticks | 更新日期: 2023-09-27 18:19:37

我需要帮助。我一直在试图弄清楚为什么javautil日期在从C# ticks转换后延迟了5个小时。

在C#中，日期是2013年8月6日上午11:02:07，我将此日期转换为ticks，然后将其作为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 util日期是6月8日星期六06:02:07 CDT 2013

请注意，小时相差5小时。

有什么建议吗？

C#Ticks转换为java util date；日期比原因晚了5个小时

您正在构建自1970年1月1日UTC以来基于毫秒的java.util.Date。您似乎在纠正这样一个事实，即.net的System.DateTime.Ticks基于1/10001，是10000个刻度到一毫秒。这是正确的，但您忘记了调整到UTC。

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

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

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

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

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

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

有一些解决方案，例如使用DateTimeOffset而不是DateTime，或者使用Noda Time库而不是内置类型。你可以在这里和这里阅读更多关于这些问题的信息。

时间并没有落后5小时，而是完全相同的时间。问题出在你打印的方式上。

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

java.util.date会自动更正您的时区。请参阅以下问题：如何设置java.util.Date的时区？

ctime是UTC（世界协调时间），这是一个参考格林威治的时间标准。你在中央时间表达你的时间。这就是你的不同。

相关文章：