Explanation for Timespan Differences Between C# and JavaScript

Question

This is based on Computing milliseconds since 1970 in C# yields different date than JavaScript and C# version of Javascript Date.getTime().

For all of these calculations, assume they are being done in Central Standard Time, so 6 hours behind UTC (this offset will come up again later).

I understand that JavaScript Date objects are based on the Unix Epoch (Midnight on Jan 1, 1970). So, if I do:

//remember that JS months are 0-indexed, so February == 1
var d = new Date(2014,1,28);
d.getTime();

My output will be:

1393567200000

Which represents the number of milliseconds since the Unix Epoch. That's all well and good. In the linked questions, people were asking about translating this functionality into C# and the "naive" implementation usually looks something like this:

//the date of interest in UTC
DateTime e = new DateTime(2014, 2, 28, 0, 0, 0, DateTimeKind.Utc);
//the Unix Epoch
DateTime s = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
//the difference between the two
TimeSpan t = (e - s);
var x = t.TotalMilliseconds;
Console.WriteLine(x);

Which produces output:

1393545600000

That's a difference of 21,600,000 milliseconds, or 6 hours: the exact offset from UTC for the time zone in which these calculations were done.

To get the C# implementation to match the JavaScript, this is the implemenation:

//DateTimeKind.Unspecified
DateTime st=new DateTime(1970,1,1);
//DateTimeKind.Unspecified
DateTime e = new DateTime(2014,2,28);
//translate e to UTC, but leave st as is
TimeSpan t= (e.ToUniversalTime()-st);
var x = t.TotalMilliseconds;
Console.WriteLine(x);

Which will give me output matching the JavaScript output:

1393567200000

What I have yet to find is an explanation for why we leave the DateTime representing the Unix Epoch with a DateTimeKind of Unspecified to be able to match JavaScript. Shouldn't we get the correct result using DateTimeKind.Utc? What detail am I not understanding? This is a purely academic question for me, I'm just curious about why this works this way.

Answer 1

As you correctly point out, .getTime() returns "the number of milliseconds since 1 January 1970 00:00:00 UTC."

Which means that .getTime is (as you noticed) including the offset from UTC in the calculation.

In order to make the C# code reflect this, the time you're subtracting from must include time zone information, while 1 January 1970 00:00:00 must be a UTC time.

This might be easier to understand with a few examples. Given:

DateTime e = new DateTime(2014, 2, 28, 0, 0, 0);
DateTime s = new DateTime(1970, 1, 1, 0, 0, 0);

1. e - s is incorrect because s is not a UTC time.
2. e.ToUniversalTime() - s.ToUniversalTime() is incorrect because e no longer includes the offset from UTC (like the calculation in JavaScript does)
3. e.ToUniversalTime() - s is correct because we're using the UTC time and the time we're subtracting includes the offset from UTC.

This was easier for me to see when I dealt with DateTime.Ticks directly:

e.Ticks // 635291424000000000
s.Ticks // 621355968000000000

e.Ticks - s.Ticks // 13935456000000000 ("naive" implementation)
e.ToUniversalTime().Ticks - s.Ticks // 13935636000000000 (correct output)

Again, the last example meets all of our requirements. The Unix epoch is in UTC, while the time we're dealing with still has its original offset.

Answer 2

I understand that JavaScript Date objects are based on the Unix Epoch (Midnight on Jan 1, 1970).

Yes, they are. Internally, it's just a number of milliseconds from the epoch. But when you call the date constructor, or look at the output from .toString(), it is using the local time of where the code is running.

If you want the input to be specified in UTC, then you have to use a different incantation:

var ts = Date.UTC(2014,1,28);  // returns a numeric timestamp, not a Date object

var dt = new Date(ts);         // if you want a date object

var s = dt.toUTCString();      // if you want the output to be in UTC