TLDR: You cannot reliably convert that date-only value, send a string instead...

...or at least that is how almost all of these answers should start off.

There is a number of conversion issues that are happening here.

This Is a Date Without Time

Something everybody seems to be missing is how many trailing zeros there are in the question - it is almost certainly started out as a date without time:

/Date(1224043200000)/ 

When executing this from a javascript console as a new Date (the basis of many answers)

new Date(1224043200000) 

You get:

The original asker was probably in EST and had a pure date (sql) or a DateTime (not DateTimeOffset) with midnight.

In other words, the intention here is that the time portion is meaningless. However, if the browser executes this in the same timezone as the server that generated it it doesn't matter and most of the answers work.

Bit By Timezone

But, if you execute the code above on a machine with a different timezone (PST for example):

You'll note that we are now a day behind in this other timezone. This will not be fixed by changing the serializer (which will still include timezone in the iso format)

The Problem

Date (sql) and DateTime (.net) do not have timezone on them, but as soon as you convert them to something that does (javascript inferred thru json in this case), the default action in .net is to assume the current timezone.

The number that the serialization is creating is milliseconds since unix epoch or:

(DateTimeOffset.Parse("10/15/2008 00:00:00Z") - DateTimeOffset.Parse("1/1/1970 00:00:00Z")).TotalMilliseconds; 

Which is something that new Date() in javascript takes as a parameter. Epoch is from UTC, so now you've got timezone info in there whether you wanted it or not.

Possible solutions:

It might be safer to create a string property on your serialized object that represents the date ONLY - a string with "10/15/2008" is not likely to confuse anybody else with this mess. Though even there you have to be careful on the parsing side: https://stackoverflow.com/a/31732581

However, in the spirit of providing an answer to the question asked, as is:

function adjustToLocalMidnight(serverMidnight){ var serverOffset=-240; //injected from model? <-- DateTimeOffset.Now.Offset.TotalMinutes var localOffset=-(new Date()).getTimezoneOffset(); return new Date(date.getTime() + (serverOffset-localOffset) * 60 * 1000) } var localMidnightDate = adjustToLocalMidnight(new Date(parseInt(jsonDate.substr(6)))); 

TLDR: You cannot reliably convert that date-only value, send a string instead...

...or at least that is how almost all of these answers should start off.

There is a number of conversion issues that are happening here.

This Is a Date Without Time

Something everybody seems to be missing is how many trailing zeros there are in the question - it almost certainly started out as a date without time:

/Date(1224043200000)/ 

When executing this from a javascript console as a new Date (the basis of many answers)

new Date(1224043200000) 

You get:

The original asker was probably in EST and had a pure date (sql) or a DateTime (not DateTimeOffset) with midnight.

In other words, the intention here is that the time portion is meaningless. However, if the browser executes this in the same timezone as the server that generated it doesn't matter and most of the answers work.

Bit By Timezone

But, if you execute the code above on a machine with a different timezone (PST for example):

You'll note that we are now a day behind in this other timezone. This will not be fixed by changing the serializer (which will still include the timezone in the iso format)

The Problem

Date (sql) and DateTime (.net) do not have timezone on them, but as soon as you convert them to something that does (javascript inferred thru json in this case), the default action in .net is to assume the current timezone.

The number that the serialization is creating is milliseconds since Unix epoch or:

(DateTimeOffset.Parse("10/15/2008 00:00:00Z") - DateTimeOffset.Parse("1/1/1970 00:00:00Z")).TotalMilliseconds; 

Which is something that new Date() in javascript takes as a parameter. Epoch is from UTC, so now you've got timezone info in there whether you wanted it or not.

Possible solutions:

It might be safer to create a string property on your serialized object that represents the date ONLY - a string with "10/15/2008" is not likely to confuse anybody else with this mess. Though even there you have to be careful on the parsing side: https://stackoverflow.com/a/31732581

However, in the spirit of providing an answer to the question asked, as is:

function adjustToLocalMidnight(serverMidnight){ var serverOffset=-240; //injected from model? <-- DateTimeOffset.Now.Offset.TotalMinutes var localOffset=-(new Date()).getTimezoneOffset(); return new Date(date.getTime() + (serverOffset-localOffset) * 60 * 1000) } var localMidnightDate = adjustToLocalMidnight(new Date(parseInt(jsonDate.substr(6)))); 

TLDR: You cannot reliably convert that date-only value, send a string instead...

...or at least that is how almost all of these answers should start off.

There is a number of conversion issues that are happening here.

This Is a Date Without Time

Something everybody seems to be missing is how many trailing zeros there are in the question - it is almost certainly started out as a date without time:

/Date(1224043200000)/ 

When executing this from a javascript console as a new Date (the basis of many answers)

new Date(1224043200000) 

You get:

The original asker was probably in EST and had a pure date (sql) or a DateTime (not DateTimeOffset) with midnight.

In other words, the intention here is that the time portion is meaningless. However, if the browser executes this in the same timezone as the server that generated it it doesn't matter and most of the answers work.

Bit By Timezone

But, if you execute the code above on a machine with a different timezone (PST for example):

You'll note that we are now a day behind in this other timezone, causing the parse to return a string that is also a day behind. This will not be fixed by changing the serializer (which will still include timezone in the iso format)

The Problem

Date (sql) and DateTime (.net) do not have timezone on them, but as soon as you convert them to something that does (javascript inferred thru json in this case), the default action in .net is to assume the current timezone.

The number that the serialization is creating is milliseconds since unix epoch or:

(DateTimeOffset.Parse("10/15/2008 00:00:00Z") - DateTimeOffset.Parse("1/1/1970 00:00:00Z")).TotalMilliseconds; 

Which is something that new Date() in javascript takes as a parameter. Epoch is from UTC, so now you've got timezone info in there whether you wanted it or not.

Possible solutions:

It might be safer to create a string property on your serialized object that represents the date ONLY - a string with "10/15/2008" is not likely to confuse anybody else with this mess. Though even there you have to be careful on the parsing side: https://stackoverflow.com/a/31732581

However, in the spirit of providing an answer to the question asked, as is:

function adjustToLocalMidnight(serverMidnight){ var serverOffset=-240; //injected from model? <-- DateTimeOffset.Now.Offset.TotalMinutes var localOffset=-(new Date()).getTimezoneOffset(); return new Date(date.getTime() + (serverOffset-localOffset) * 60 * 1000) } var localMidnightDate = adjustToLocalMidnight(new Date(parseInt(jsonDate.substr(6)))); 

TLDR: You cannot reliably convert that date-only value, send a string instead...

...or at least that is how almost all of these answers should start off.

There is a number of conversion issues that are happening here.

This Is a Date Without Time

Something everybody seems to be missing is how many trailing zeros there are in the question - it is almost certainly started out as a date without time:

/Date(1224043200000)/ 

When executing this from a javascript console as a new Date (the basis of many answers)

new Date(1224043200000) 

You get:

The original asker was probably in EST and had a pure date (sql) or a DateTime (not DateTimeOffset) with midnight.

In other words, the intention here is that the time portion is meaningless. However, if the browser executes this in the same timezone as the server that generated it it doesn't matter and most of the answers work.

Bit By Timezone

But, if you execute the code above on a machine with a different timezone (PST for example):

You'll note that we are now a day behind in this other timezone. This will not be fixed by changing the serializer (which will still include timezone in the iso format)

The Problem

Date (sql) and DateTime (.net) do not have timezone on them, but as soon as you convert them to something that does (javascript inferred thru json in this case), the default action in .net is to assume the current timezone.

The number that the serialization is creating is milliseconds since unix epoch or:

(DateTimeOffset.Parse("10/15/2008 00:00:00Z") - DateTimeOffset.Parse("1/1/1970 00:00:00Z")).TotalMilliseconds; 

Which is something that new Date() in javascript takes as a parameter. Epoch is from UTC, so now you've got timezone info in there whether you wanted it or not.

Possible solutions:

It might be safer to create a string property on your serialized object that represents the date ONLY - a string with "10/15/2008" is not likely to confuse anybody else with this mess. Though even there you have to be careful on the parsing side: https://stackoverflow.com/a/31732581

However, in the spirit of providing an answer to the question asked, as is:

function adjustToLocalMidnight(serverMidnight){ var serverOffset=-240; //injected from model? <-- DateTimeOffset.Now.Offset.TotalMinutes var localOffset=-(new Date()).getTimezoneOffset(); return new Date(date.getTime() + (serverOffset-localOffset) * 60 * 1000) } var localMidnightDate = adjustToLocalMidnight(new Date(parseInt(jsonDate.substr(6))));