Change History (35)

the thing that's always bothered me about Crockford's solution, though, is that it's asymmetrical. You can't have a Date object in the return data, of course. It seems to lend itself more to a registry approach, where certain data can be tagged, perhaps by property naming conventions or explicit wiring. Furthermore, it's unclear whether the ISO format is intended to be more capable, like the one in dojo.date.stamp. Did that ever get resolved in ES4?

Yes, it is unfortunate that the Date->ISO string is asymmetric, but it certainly isn't as asymmetric as serializing Date -> {}. It does require some knowledge or pattern matching to parse date strings back to Date objects. I am hoping to write a json parse/stringify augmenter that could help with this, being advised by JSON Schema, but for base functionality, I still believe it is best to follow Crockford's approach here. I am not sure what is meant by "more capable". I will attach my changes as diff/patches.

Kris, have you looked at dojo.date.stamp? It allows partial dates/times and is a compromise between the ISO spec and what's used in the W3C specs, with an eye towards performance and code size. It would be nice to reuse that functionality, if appropriate, and use that for an augmented json schema. Note that there used to be a 'registry' approach to the json code, but I guess that was abandoned. I'd prefer a pluggable approach rather than baking it in base.

I have looked at dojo.date.stamp. Do you want an alternate serialization of Dates for json? Still hesitant to diverge from Crockford here. Or do you want the json serializer to call dojo.date.stamp.toISOString? dojo._base.json is a _base file, and dojo.data.stamp is not. Would you really want that dependency?
As far augmenting json parsing/serialization with json schema, I would certainly do it as a plugin (in dojox). I would use AOP to add functionality when desired (still thinking about this).

dojo.date.stamp is a superset of what Crockford has, and as you say, his proposal is not final and I don't think it was even finalized by ES4.

base code can't call core code, but if you had an augmentation in dojox or dojo core, it could certainly call it. It could also be a 'mixin' in dojo core (see dojo.fx for an example) Easier to move code into base than out.

I think the fancy stuff, like date parsing should be an augmentation from dojox. However, basic Date serialization seems like it is currently broken (outputting {}), and should be fixed in base, and it seems like avoiding dependency issues with dojo.data.stamp and simply using the providing patch would be the easiest solution. Or are you concerned about the patch being too big?

A little concerned about code size, but mostly arguing that an asymmetrical solution is potentially confusing and that it's best to solve in one place, not two. But I don't feel all that strongly about it.

I'm +1 on the code size change, -1 on the date. It should be ISO or nothing. Date.toString() is horrible and does implementation- (browser) specific things. I'd rather have something that causes an error than provide data that's inconsistent. Also, should it be it === null ?

Yikes. People have been wrestling with this problem for a while and while this may be the closest I've seen to a type-specific solution in JSON, well, there are a couple of reasons not to follow MS here. One is that Crockford does have a solution offered in ES31, so this would diverge from the standard. (We should probably consider supporting stringify/parse) MS does seem to rely on a real hack and not be generalizable, and by not using ISO format, it invites more timezone problems, etc. I know it's unfortunate that the reviver/replacer system offered in ES31 ends up doing this more on a schema (particular named properties or property patterns) rather than a type, but that's because unfortunately JS doesn't have a native Date type, so it really just doesn't fit well into JSON to do it any other way.

Yeah - I don't figure that the patch will be good enough for inclusion into base any time soon - but at least it provides a solution for someone who it might be "good enough" for...and doesn't mind patching their own source.

However, I don't quite follow on the timezone issues that it brings...I thought that date.getTime() and new Date(seconds) are based off of GMT...

See also #8111. Matching these signatures would provide a solution the problem, though maybe not in a way that makes everyone happy.

@toonetown: well, one reason not to use the Unix epoch is because it assumes a particular time zone. If you want to represent a particular date, without regards to absolutes -- a common scenario -- you'll inevitably end up off by a day in some other timezone.

Fixed with latest checkin. Note, that there are some differences between how JSON.stringify(new Date(12)) works in browsers:
IE8: "1970-01-01T00:00:00Z"
WebKit & FF: "1970-01-01T00:00:00.012Z"
IE6-7 (our code): "1970-01-01T00:00:00.01Z"