5

Our application heavilly relies on javascript (jQuery). So there are lots of 'application/json' requests.

We've been struggling with dates for some time, but despite our efforts we couldn't figure out how to deal with it in ASP.NET MVC application.

Here what we want:

  1. Serialize/deserialize DateTime objects on the server side (preferably with DateTimeKind.Utc).
  2. Work with Date object on the client side. Work with it in UTC. Format dates somehow.

Here are problems:

  1. Date client object is always with end-user's timezone. JSON.stringify(new Date()) automatically does a shift.

    JSON Stringify changes time of date because of UTC

    This question helper a bit, but we need to remember to shift dates before sending it to the server. We also need to remember that we need a shift once we do new Date('2012-10-19T10:23:47.778Z') We know that JSON is not aware of dates, but it would be nice to have analogue of JSON.parse that would parse dates.

  2. We use Newton Json.net to serialize/deserialize dates, but it does it in DateTimeKind.Unspecified

Question:

Is there an elegant way to work with dates both on the server and client? We need it as a cross-cutting thing in the whole application.

UPD:

I had to put it more clearly. In our application we don't need take into account client time zones since we operate only with dates.

So if server returns 2012-10-19T10:23:47.778Z', we need Date object:

Fri Oct 19 2012 10:23:47 GMT+0300 (Kaliningrad Standard Time)

Not

Fri Oct 19 2012 13:23:47 GMT+0300 (Kaliningrad Standard Time) (Date is shifted)

Community
  • 1
  • 1
  • Doesn't `JSON.stringify` convert the date *to* UTC? – James Oct 19 '12 at 10:58
  • After experiencing these problems myself, some guy asked me the following: "Do you really need the object itself on the client or just the correct notation?". He was right in my case and decided to return the string notation of the correct date, formatted by the correct Culture. – Rob Angelier Oct 19 '12 at 11:08

2 Answers2

4

I would strongly suggest reading following post:

Which leads to general conclusion that you should use ISO dates:

  • By using modern browser .toJSON() method on client side
  • By properly configuring JSON serialization on server side (JsonNetFormatter with IsoDateTimeConverter)
tpeczek
  • 23,867
  • 3
  • 74
  • 77
1

Probably the best way is to send a time value as milliseconds since 1970-01-01T00:00:00Z (i.e. UTC), then you can just do new Date(timeValue) and there's your date object set to that UTC time. It will return date and time based on the client system time zone setting.

e.g. for me:

alert(new Date(0)); // Thu Jan 01 1970 10:00:00 GMT+1000 (EST)

If you mess with that date object on the client (say add a day) you can just send back the time value:

var timeValue = 1350518400000; // 2012-20-18T00:00:00Z
var date = new Date(timeValue);
alert(date);                   // 2012-10-18T10:00:00UTC+1000

// add a day
date.setDate(date.getDate() + 1); 
alert(date.getTime());         // 1350604800000

Subtract the first timeValue from the second and you get 86400000, which is the milliseconds in one day (it will be an hour either way if the day crosses a daylight saving change boundary). Do what you like with the time value at the sever, keep it as a number or convert it to a date string.

RobG
  • 142,382
  • 31
  • 172
  • 209
  • One gotcha is the .NET DateTime epoch and ticks are different than JavaScript's. https://msdn.microsoft.com/en-us/library/system.datetime.ticks(v=vs.110).aspx and http://stackoverflow.com/questions/7966559/how-to-convert-javascript-date-object-to-ticks – Jasen Feb 03 '16 at 02:25