纪元时间（自 1970 年以来的刻度） - Mac 与 Windows答案

【问题标题】：Epoch Time (Ticks since 1970) - Mac vs. Windows纪元时间（自 1970 年以来的刻度） - Mac 与 Windows
【发布时间】：2011-01-03 22:13:01
【问题描述】：

我有一些返回 JSON 的 C# Web 服务。 .NET JavaScriptSerializer 以纪元时间（自 1970 年以来的毫秒数）返回日期。在任何 Windows 机器上，基于 Web 的应用程序都会毫无问题地将毫秒数处理回正确的日期。

在我的 Mac 上，日期有时会相差 1 小时。不是每次。只有某些时候。这也发生在我正在构建的 iPhone 前端。

起初我以为我在将毫秒除以 1000 以创建有效的 Objective-C NSDate 对象时丢失了一些精度。然后我在 Mac Firefox 上用相同的时间戳测试了 javascript 中的日期创建，并得到了相同的 1 小时偏移量。

有什么想法吗？谢谢...

编辑：我还在 XCode 的控制台中注意到，创建的日期旁边有 -4 或 -5。我假设这是一个 GMT 偏移量。这些似乎与日期是否偏移 1 小时无关。因此，一些 -4 日期和一些 -5 日期是正确的，其中一些日期是偏移的。

编辑：使用示例：

console.log(new Date(-1173643200000));

返回 1932 年 10 月 23 日星期日 00:00:00 GMT-0400 (EST)

console.log(new Date(-1031515200000));

返回 1937 年 4 月 24 日星期六 23:00:00 GMT-0500 (EST)

NSDate* date = [NSDate dateWithTimeIntervalSince1970:ticks / 1000];

-589320000000 =
1951-04-30 00:00:00 -0400

-1173643200000 =
1932-10-22 23:00:00 -0500

（这个在 Firebug 控制台返回正确，在 XCode 控制台返回错误）

-1303416000000 =
1928-09-12 00:00:00 -0400

-1492545600000 =
1922-09-15 00:00:00 -0400

-1263668400000 =
1929-12-16 00:00:00 -0500

-1252094400000 =
1930-04-29 00:00:00 -0400

-1046458800000 =
1936-11-03 00:00:00 -0500

-1298746800000 =
1928-11-05 00:00:00 -0500

-1031515200000 =
1937-04-24 23:00:00 -0500

（在 Firebug 控制台和 XCode 控制台中都返回错误）

-910465200000 =
1941-02-24 00:00:00 -0500

-1152648000000 =
1933-06-23 00:00:00 -0400

-1109793600000 =
1934-10-31 23:00:00 -0500

Microsoft/Mozilla/Apple 是否有可能在定义夏令时开始的时间时有冲突的规则？

编辑： Mac Firefox 和 Windows Firefox 对于 -1031515200000 得到不同的结果。两台机器都设置为相同的时区。

【问题讨论】：

标签： json macos date epoch

【解决方案1】：

听起来很像其中一个是给你自纪元以来的滴答声，另一个是给你自 1970 年 1 月 1 日以来的毫秒在你当地的时区......或者他们正在解释这样的数据。夏天所有的“错误”日期，是否有任何机会？（编辑：现在我看到了你的编辑，我看到你的想法是一样的。）

您能否给我们一些示例值以及您在各个地方使用的代码？你确定值本身是错误的，而不仅仅是显示问题？

如果可能，最好提供自 1970 年 1 月 1 日午夜 UTC 以来的瞬间。大多数平台都提供了一种相当简单的处理方式。在.NET 中，如果您使用DateTimeOffset 而不是DateTime，您应该至少避免其中一些问题。（当然，在未来，正确的解决方案是使用Noda Time。但目前还没有。）

编辑：好的，现在您已经提供了示例数据，看起来实际上在返回的 instant 中没有任何不一致......这是不同的本地时间转换。当然，不同的平台很可能对历史时区信息有不同的看法——有些可能只是有一个永久的规则，他们认为这是正确的，永远是正确的，其他人会知道涉及的各种变化。我会预计大多数平台会考虑这些天的历史变化，诚然...

至少在 iPhone 上，我希望您能够编写代码来找出时区转换，然后将其与 .NET 通过TimeZoneInfo 提供的内容进行比较。

您的应用程序实际上对这些信息做了什么？您对它感兴趣的是一个瞬间（可以被视为不同时区）还是只是当地时间？

【讨论】：

老实说，我只是想传递生日，我通过序列化一个技术含量极低的 DateTime.ToString("d") 轻松解决了这个问题。我很确定现代日期很好，但是当我写这个问题时我不知道这一点。在这一点上，我只是希望有人可以用一些 DST 开始/结束日期的迂腐索引来证实我们的怀疑。我想我可以通过在各种平台上写出一些有问题的日期的表格来证明自己的不一致。

【解决方案2】：

我的猜测是关于 DST 何时结束和开始的平台差异。当前年份的时间戳是否正确？

【讨论】：

我不是 100% 知道你是正确的，但这似乎是最可能的原因。

【解决方案3】：

我敢打赌，这是一个时区问题，您的 Mac 将时间戳转换为您的本地时区，对于某些时间戳是夏令时 (DST)，而有些不是，与 UTC 相比会产生一小时的时差，这确实没有夏令时。

【讨论】：

我在美国东部时间。 UTC 和 EST 之间的差异是 4-5 小时。