标签云

微信群

扫码加入我们

WeChat QR Code

I'm taking my first crack at Ajax with jQuery. I'm getting my data onto my page, but I'm having some trouble with the JSON data that is returned for Date data types. Basically, I'm getting a string back that looks like this:/Date(1224043200000)/From someone totally new to JSON - How do I format this to a short date format? Should this be handled somewhere in the jQuery code? I've tried the jQuery.UI.datepicker plugin using $.datepicker.formatDate() without any success.FYI: Here's the solution I came up with using a combination of the answers here:function getMismatch(id) {$.getJSON("Main.aspx?Callback=GetMismatch",{ MismatchId: id },function (result) {$("#AuthMerchId").text(result.AuthorizationMerchantId);$("#SttlMerchId").text(result.SettlementMerchantId);$("#CreateDate").text(formatJSONDate(Date(result.AppendDts)));$("#ExpireDate").text(formatJSONDate(Date(result.ExpiresDts)));$("#LastUpdate").text(formatJSONDate(Date(result.LastUpdateDts)));$("#LastUpdatedBy").text(result.LastUpdateNt);$("#ProcessIn").text(result.ProcessIn);});return false;}function formatJSONDate(jsonDate) {var newDate = dateFormat(jsonDate, "mm/dd/yyyy");return newDate;}This solution got my object from the callback method and displayed the dates on the page properly using the date format library.


This might be interesting: hanselman.com/blog/…

2019年06月26日59分44秒

The /Date(...)/ format is specific to Microsoft's built-in JSON Date format - it's not part of any standard, and JSON, coming from Javascript, has a standard: The ISO format Javascript specifies: stackoverflow.com/a/15952652/176877So, this question is specific to Microsoft's JSON Date format. I modified the title to clarify this.

2019年06月26日59分44秒

You're kidding! Microsoft have stamped their own spin on JSON! and on dates!! When will they learn!

2019年06月26日59分44秒

Use Newtonsoft JSON on the .NET side and to have nice typed values on the JS side, just use: github.com/RickStrahl/json.date-extensions

2019年06月26日59分44秒

You could use JSON++ instead of JSON. JSON++is the same than JSON but with support for JavaScript types such as Date.

2019年06月26日59分44秒

Broam: Both methods (the replace function and this answer) would have to change if MS changes the format.

2019年06月26日59分44秒

Could you please update it with the radixvar date = new Date(parseInt(jsonDate.substr(6), 10));

2019年06月25日59分44秒

JamesKyburz: Every rule has exceptions, and I think this is when an exception applies. The JSON date numbers from .NET never have a leading "0", so we can safely leave out the radix.

2019年06月26日59分44秒

It's worth noting that this date format is pretty bad and the general move is to ISO-8601 formatted dates in JSON. See hanselman.com/blog/…

2019年06月26日59分44秒

This approach fails to consider timezone so can cause serious problems when your server and users are in different timezones. I posted an answer below that explains a very quick and easy way to deal with it on WCF and Javascript sides: stackoverflow.com/a/10743718/51061

2019年06月26日59分44秒

There's nothing wrong with the line, the sequence is \// . First slash is escaped so it does not count like a comment. It's your editor tricking you, the line will work fine.

2019年06月26日59分44秒

rball, nonsense: jsonDate = new Date(+jsonDate.replace(/\/Date\((\d+)\)\//, '$1'));

2019年06月25日59分44秒

pst was correct, it is possible to do this in a variety of ways without 'eval'. Crockford says that 'eval Is Evil' because it is less readable and is less secure, furthermore he may further imply that it is less efficient and more dangerous because it hits the javascript compiler.

2019年06月26日59分44秒

Edy: new Function is almost as bad as eval: dev.opera.com/articles/view/efficient-javascript/…

2019年06月26日59分44秒

Edy: That is another form of eval, and is just as 'evil'. Parse the string instead (see my answer below)

2019年06月26日59分44秒

The JavaScript Date constructor can parse the string for you: new Date("2009-04-12T20:44:55")

2019年06月26日59分44秒

Warning - The Date() Constructor formats and parsing are non-standard before ECMAScript 6.For example, IE 9 treats the date you give the constructor as a local time even if it is in IS0-8601 whichs is implied as UCT everywhere else.Don't rely on the date constructor if you support older browsers.codeofmatt.com/2013/06/07/…

2019年06月26日59分44秒

Sending non-UTC date will sooner or later get you into trouble.

2019年06月26日59分44秒

this is wrong, new Date(1224043200000-0600) will only subtract 600 from the date, in this case 600 miliseconds, not 6 hours as it should.

2019年06月26日59分44秒

ariel: Have a look at Javascript Date from milliseconds and timezone

2019年06月26日59分44秒

I think the timezone offset is only included if you have a timezone on the DateTime object in .NET (which is the default behaviour). If your date is in UTC, use DateTime.SpecifyKind(date, DateTimeKind.UTC) and you'll get the proper UTC value when it serializes out, with no offset, which you can then convert back to the user's timezone as needed. If it's in local time, use .ToUniversalTime() and it'll convert to UTC, and have the "Kind" already specified for you.

2019年06月26日59分44秒

in javascript -0100 will be a binary string so be carefull!

2019年06月26日59分44秒

once you have got the date converted from WCF to JS, how about reverse. You gotta date as integer (using date.getTime() ) which you want to pass to the same WCF?

2019年06月26日59分44秒

That's what I would have thought too except it ends up being: var thedate = /Date(1224043200000)/; at least for me...

2019年06月26日59分44秒

Date() and Date(1224043200000) both give the same result in both Chrome and Firefox.Not sure if this worked in old browsers, but this answer doesn't work in browsers now.

2019年06月26日59分44秒

James, Yes it is giving browser current date. :(

2019年06月26日59分44秒

You need to write it as "new Date(1224043200000)".

2019年06月26日59分44秒

Just an improvement for the method above.function formatearFecha(fec) { var value = new Date (parseInt(fec.replace(/(^.*()|([+-].*$)/g, '')) );var mes = value.getMonth(); var dia = value.getDate(); var date = dia + "/" + mes + "/" + value.getFullYear();if (dia < 10) date = date.substr(0, 0) + '0' + dia + date.substr(1); if (mes < 10) date = date.substr(0, 3) + '0' + mes + date.substr(4); return date; }date formatted to ddMMyyyy. Cheers!

2019年06月26日59分44秒

That's incorrect, JSON uses Javascript dates, with added timezone information-- the epoch is the same as the javascript Date class's epoch (for obvious reasons).

2019年06月26日59分44秒

BrainSlug83 - this answer provides a reference for the assertion that JSON doesn't have a built-in date type. If you disagree, please provide an alternative reference. (You're not thinking of a specific framework that has decided on a string format to represent dates are you? That's not part of the JSON standard, indeed it couldn't be because it would make it impossible to include a string that is not supposed to be taken as a date but that happens to have a set of characters that match the date pattern.)

2019年06月26日59分44秒

Just as a note: for the code to work you have to create the startsWith method of the string type

2019年06月26日59分44秒

And too bad there are more than 20 epochs to choose from. en.wikipedia.org/wiki/Epoch_(reference_date)

2019年06月26日59分44秒

That's the nice thing about standards.

2019年06月26日59分44秒

There is a standard format for dates in JSON, which is the RFC 3339 format.

2019年06月26日59分44秒

gnasher, that would be nice, but is not the case. There are no references from RFC 7159 to 3339 or vice versa. There is no de jure standard JSON date format. All that's left are de facto standards, each of which have pros/cons. That's the nice thing about standards.

2019年06月26日59分44秒

Nice idea, but what if a timezone offset is included? Better to use substr(6) in that case instead of slice(6,-2) -- see my answer below.

2019年06月26日59分44秒

This is a new question and should be asked as its own question and not embedded here.

2019年06月26日59分44秒

Regexp replacements are slow... It's much faster to grab the integer portion using substr(6) and pass it to parseInt() -- see my answer below.

2019年06月26日59分44秒

Also have a look at Javascript Date from milliseconds and timezone

2019年06月26日59分44秒

You made my day, thanks

2019年06月26日59分44秒

According to JSON Schema, the "date-time" format corresponds to RFC 3339, section 5.6. So you should write "yyyy-MM-ddTHH:mm:ssZ" for dates in GMT, or the Z replaced with a time zone like +hh:mm.

2019年06月26日59分44秒

The problem is that WCF and other "old" MS JSON serialization doesn't use this format, and that has to be accounted for.

2019年06月26日59分44秒

That's not legal JSON. It will only work when eval'ing with a Javascript interpreter. But if you're using a JSON decoder, it will choke.

2019年06月26日59分44秒

Agreed. And if I were just dealing with this one piece of data, I wouldn't consider it. But if I'm dealing with an object of several dates and other properties, it's easier to eval() the whole thing than pick out the properties one at a time. In the end, the root issue is the lack of a (legal) JSON date. Until that exists, we are left to our creative hacks.

2019年06月26日59分44秒

so everytime you add a new role[Authorize(Roles = "Human Resources")] , you have to compile and deploy?wow.... :)

2019年06月26日59分44秒

If this is a JSON service then the redirect seems wrong. I'd return a 404 Not Found if the input key is so invalid it can't possibly be found, (and also 404 if it genuinely is not found). When my users are not logged in I return 403 Forbidden.

2019年06月26日59分44秒

It's a "reusable" method. For example, if I wanted to get user data from another View, I can get it as long as I supply the Id. However, if the Id isn't supplied, page redirects to a list of users (Index) to select a user. Simple solution needed for the app, just the way my brain cooked it up at that time.

2019年06月26日59分44秒