大纪元时间（自1970年以来的蜱虫）-Mac与Windows-EpochTime(Tickssince1970)-Macvs.Windows

作者：手机用户2502859155 | 来源：互联网 | 2023-05-16 13:16

IhavesomeC#webservicesthatreturnJSON.The.NETJavaScriptSerializerreturnsdatesinEpochT

I have some C# web services that return JSON. The .NET JavascriptSerializer returns dates in Epoch Time (milliseconds since 1970). On any Windows machine, the web based application processes the milliseconds back into the proper date without a problem.

我有一些返回JSON的C#Web服务。 .NET JavascriptSerializer以大纪元时间(自1970年以来的毫秒)返回日期。在任何Windows计算机上,基于Web的应用程序将毫秒数处理回正确的日期而不会出现问题。

On my Mac, the dates are sometimes off by 1 hour. Not every time. Only sometimes. This is now happening on the iPhone front end I'm building as well.

在我的Mac上,日期有时会偏离1小时。不是每一次。只是有时。现在正在我正在构建的iPhone前端上发生这种情况。

I thought at first that I had lost some precision when dividing the milliseconds by 1000 to create a valid Objective-C NSDate object. Then I tested date creation in Javascript on Mac Firefox with the same timestamp and got the same 1 hour offset.

我首先想到,在将毫秒除以1000时,我已经失去了一些精度,以创建有效的Objective-C NSDate对象。然后我在Mac Firefox上使用相同的时间戳在Javascript中测试日期创建,并获得相同的1小时偏移量。

Any ideas? Thanks...

有任何想法吗?谢谢...

Edit: I also noticed in the Console in XCode that the date created had a -4 or -5 next to it. I'm assuming that is a GMT offset. Those seem to vary independent of whether or not the date is offset by 1 hour. So some -4 dates and some -5 dates are correct and some of either one are offset.

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

Edit: Examples using:

编辑:使用示例:

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

returns Sun Oct 23 1932 00:00:00 GMT-0400 (EST)

返回Sun Oct 23 1932 00:00:00 GMT-0400(EST)

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

returns Sat Apr 24 1937 23:00:00 GMT-0500 (EST)

返回Sat Apr 24 1937 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

(This one returns correct in Firebug Console, wrong in XCode Console)

(这个在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

(Returns wrong in both Firebug Console and XCode Console)

(在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

Is it possible that Microsoft/Mozilla/Apple have conflicting rules defining when Daylight Saving Time started back then?

微软/ Mozilla / Apple是否有可能在夏令时开始时制定相互矛盾的规则?

Edit: Mac Firefox and Windows Firefox get different results for -1031515200000. Both machines are set to the same timezone.

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

3 个解决方案

#1

My guess would be platform differences regarding when DST ends and begins. Are the timestamps for current years coming out right?

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

#2

It sounds very much like one of them is giving you ticks since the epoch, and the other is giving you milliseconds since 1970 January 1st in your local time zone... or they're interpreting the data that way. Are all the "wrong" dates in the summer, by any chance? (EDIT: Now I've seen your edit, I see you're thinking along the same lines.)

这听起来非常像其中一个是从纪元开始给你打勾,另一个是你自当地时区1970年1月1日以来的毫秒时间......或者他们正在以这种方式解释数据。在夏天,所有“错误”的日期都是机会吗? (编辑:现在我看到了你的编辑,我看到你在思考同样的问题。)

Could you give us some sample values, and the code you're using in various places? Are you sure that the value itself is wrong, and it's not just a display issue?

你能给我们一些样本值,以及你在不同地方使用的代码吗?你确定价值本身是错的吗,它不只是一个显示问题?

If possible, it would be a good idea to provide instants since the midnight January 1st 1970 UTC. Most platforms give a reasonably simple way of handling that. In .NET, if you use DateTimeOffset instead of DateTime you should avoid at least some of these problems. (In the future, of course, the right solution will be to use Noda Time. But not yet.)

如果可能的话,自UTC 1970年1月1日午夜以来提供瞬间是个好主意。大多数平台提供了一种相当简单的处理方式。在.NET中,如果使用DateTimeOffset而不是DateTime,则应该至少避免其中一些问题。 (当然,将来,正确的解决方案是使用Noda Time。但还没有。)

EDIT: Okay, now you've provided sample data, it doesn't look like there's actually any inconsistency in the instant returned... it's the conversion into the local time that's different. It's very possible that different platforms will have different views of historical time zone information, certainly - some may just have a permanent rule that they assume will have been right and will be right forever, others will know about the various changes involved. I would expect most platforms to take historical changes into account these days, admittedly...

编辑:好的,现在你已经提供了样本数据,它看起来并不像返回的瞬间有任何不一致......它是转换为不同的本地时间。很可能不同的平台对历史时区信息有不同的看法,当然 - 有些人可能只有一个永久性的规则,他们认为这些规则是正确的并且永远是正确的,其他人会知道所涉及的各种变化。我希望大多数平台最近都会考虑历史变化,诚然......

On the iPhone at least, I'd expect you to be able to write code to find out the time zone transitions, and then compare that with what .NET gives via TimeZoneInfo.

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

What is your application actually doing with this information? Are you interested in it as an instant in time (which can be regarded in different time zones) or just the local time?

您的应用程序实际上对此信息做了什么?您是否及时(可以在不同时区看到)或当地时间对它感兴趣?

#3

I bet it's a timezone thing, where your Mac converts timestamps to your local timezone, which for some timestamp is in daylight savings time (DST), and some are not, causing a one hour time difference compared to UTC, which does not have DST.

我打赌这是一个时区的事情,你的Mac将时间戳转换为你的本地时区,有些时间戳是夏令时(DST),有些不是,导致与UTC相比有一小时的时差,没有DST 。