Encoding/Decoding date from record

[ghost277]

There seems to be an issue with the JSON encode and decode functions, prohibiting them to be used in tandem for a date item.
The following code showcases the issue:

ListGridRecord record = new ListGridRecord();
Date date = new Date();
record.setAttribute("myDateField", date);
ListGridRecord rec = new ListGridRecord(JSON.decode(JSON.encode(record.getJsObj())));
Date dt = rec.getAttributeAsDate("myDateField"));

The last line never assigns the date value.

Tested with SmartClient Version: v8.1p_2012-11-28/LGPL Development Only (built 2012-11-28).
I have tested this under Chrome and Firefox (latest releases for both browsers) on both Windows (7 64bit) and Linux (Ubuntu 12.10 64bit).
Though I doubt it is platform specific.

The only related log I could get was under dev mode:

JavaScriptException: (TypeError) @com.smartgwt.client.util.JSOHelper::getAttributeAsDate(Lcom/google/gwt/core/client/JavaScriptObject;Ljava/lang/String;)
([JavaScript object(8), string: 'myDateField']): Object 2013-03-11T14:15:29 has no method 'getTime'

which is of course strange as the format of the encoding output is controlled by SmartGWT and it should be accepted by the decode, on the opposite direction.

[Isomorphic]

See the docs for JSON.encode() and note the special mention of round-tripping dates.

[ghost277]

I checked the proposed docks and updated my code example to utilize the JSONEncoder setDateFormat and encode methods. However the problem I have is that for the version of SmartGWT I am using - 2.5p, nightly build of 20121128 - there is no decode method at the JSONEncoder. This leads me to use the JSON.decode method, which of course doesn't work as expected. Apart from updating to newer version - there are other reasons that prohibit me doing so at the moment - is there a workaround fix for this issue at my version?

Another question I have is, since date formats are required to encode them, why there isn't one set as default (e.g. XML Schema) and used in my case to allow the correct encoding/decoding of the date object?

[Isomorphic]

There's no workaround because there's no known bug. We're not sure why you say JSON.decode() "of course doesn't work as expected".. if you think there's an issue here, please show how it can be reproduced.

As far as the general question, JSON as a format does not specify an encoding for dates. So any standard JSON decoder will just give you a String if it finds a Date encoded as an XML Schema string (or encoded in any other way). That's why you need to use setDataFormat(), because it creates something that isn't strictly JSON, but will result in actual dates being created on JSON.decode().

[ghost277]

OK, maybe I wasn't clear enough. After your comment of using JSONEncode, I updated my code example to utilize it during the encoding phase. But, since at the version I am using, the JSONEncoder doesn't provide a decode method, I had to still use the JSON.decode method. This still gives error, when I try to access the date attribute at the reconstructed record. The code is as following:

ListGridRecord record = new ListGridRecord();
Date date = new Date();
record.setAttribute("myDateField", date);

JSONEncoder jsonEncoder = new JSONEncoder();
jsonEncoder.setDateFormat(JSONDateFormat.XML_SCHEMA);
ListGridRecord rec = new ListGridRecord(JSON.decode(jsonEncoder.encode(record.getJsObj())));
Date dt = rec.getAttributeAsDate("myDateField"));

So, yes, the dt has no value, the code crushes after that point and, as far as I can see it from my point of view, I should have been able to retrieve the date data I put in a record, after I encoded it and decoded it. Unless, I am doing something wrong, - please point me to the correct way to achieve this under 2.5 version - I would consider this either a bug, or you should state that for the 2.5 version you do not support Date objects encoding.

[Isomorphic]

Uhm.. the docs tell you that to round-trip dates, you must use dateFormat:dateConstructor. You have configured xmlSchema instead.

[ghost277]

OK thanks for that, I kind of missed it under the "noise" of the Javadocs formatting, and assumed that both options would result in correct decoding of dates. Setting it to JSONDateFormat.DATE_CONSTRUCTOR solves my issue.
Again thanks for your time and efforts.