-
-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correct bad Date.prototype.toJSON polyfills from elsewhere #95
Comments
json2.js Date.prototoype.toJSON is also not generic. If json2.js is updated to handle extended dates correctly but not to be generic then the following check would fix things.
|
Thanks, @petermichaux. Good to cross paths again! |
I admit the above feature test is ugly. A workaround that could be documented in the README?...
|
By the way, Crockford closed my tickets about improving the Date.prototype.toJSON in his json2.js. |
What about something like this? if (!Date.prototype.toJSON ||
// does Date.prototype.toJSON not do extended years properly?
!~((new Date(-62198755200000)).toJSON().indexOf('-000001')) ||
// is Date.prototype.toJSON non-generic?
~(function() {
try {
return Date.prototype.toJSON.call({toISOString:function(){return -1;}});
} catch (err) {
return true;
}
}())) { |
Additional |
Douglas Crockford's json2.js, for example, defines a Date.prototype.toJSON function that does not pad extended years with zeros as the es5-shim does in Date.prototype.toISOString does.
es5-shim can redefine a bad Date.prototype.toJSON by changing
to
This also means people using json2.js need to include json2.js in their environment before including es5-shim as defining Date.prototype.toJSON means other things will not be defined in json2.js
The text was updated successfully, but these errors were encountered: