Epoch Time (Ticks since 1970) - Mac vs. Windows

Question

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.

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.

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.

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.

Edit: Examples using:

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

returns 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)

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)

-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)

-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?

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

Answer 1

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.)

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.)

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.

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?

Answer 2

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.

Answer 3

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