Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>So, this is an ASP.NET specific Microsoft Date "standard".</p> <p>See <a href="http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx" rel="nofollow">http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx</a> why it should be avoided like the plague(1).</p> <p>In that format the first component is a UTC milliseconds offset since the UNIX epoch. The offset is TO local time, which is the opposite of the timezone offset in the JS Date string representations.</p> <p>Use</p> <pre><code>var dateString = myDate.toJSON(); </code></pre> <p>to serialize a JS Date object for sending.</p> <p>Such a serialized datetime string, which is also in UTC (aka *Z*ulu), can be used to create a Date object thusly:</p> <pre><code>var myDate = new Date(dateString); </code></pre> <hr> <p>(1) In case you need to support this old ASP.NET Date format you can convert it to a proper JS Date like this (thanks [Roy Tinker][2]):</p> <pre><code>myDate = new Date(parseInt("/Date(1377200468203+0200)/".substr(6))); </code></pre> <hr> <p><strike>I'm not familiar with that particular datetime notation.</p> <p>Is that home-grown?</p> <p>Is there documentation for that?</p> <p>If not, then you are setting yourself up for trouble trying to interpret it.</p> <p>That conversion toJSON would make it a UTC time and a few things are open for interpretation, unless documented in minute (no pun intended) detail.</p> <p>So this is my answer: Be very sure you have the above definition in normative writing.</p> <hr> <p>Now let me ramble on for a bit:</p> <p>I went through that little exercise here...</p> <p><a href="http://en.wikipedia.org/wiki/ISO_8601" rel="nofollow">http://en.wikipedia.org/wiki/ISO_8601</a> would be a good standard to base datetime notation on.</p> <p>Now, you already get that format from the server, which looks like a millisecond time value since the epoch ('1970-01-01T00:00:00Z'), (probably with a timezone offset already applied to it!) combined with a timezone offset string in HHMM.</p> <p>That's a bit scary, since those two components don't mix well.</p> <p>Evaluated as an expression 1377200468203+0200 would subtract octal! 200 milliseconds! from 1377200468203. That's clearly not what's intended.</p> <p>In ISO8601 (which this notation is not) this timezone offset would be FROM UTC, so the millisecond value would already have the 2 hour, 0 minutes offset applied to it.</p> <p>Now the code could of course run on a machine which is in a different timezone than the datetime given.</p> <p>The very crucial question is whether this millisecond datetime value has indeed the offset FROM UTC in it.</p> <p>In that case, doing var dt = new Date(1377200468203); would be wrong.</p> <p>If it is close to a daylight savings time switch time, it would be incorrect to just subtract to offset from it.</strike></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload