OData read converts Date into non-usable format in Safari

May 3, 2012 at 11:23 AM

Hi,

I was reading several other discussions which are touching on my issue but do not quite fit my problem. To sum things up here are my issues before I get into the details:
1) I do not know if I can skip the Date parsing done by data.js for a OData.read call to retrieve the "raw date" format sent by the server
2) I am not aware of a lib / datajs-property which lets me feed the OData.request with the formatted date and send the "raw date" format back to the server

Before starting to write my own parsers it would be great to know if there is a better standard way of doing things. Thanks in advance.

My goal is to read Dates with an OData service, make them nicely readable in the browser, then to manipulate them and update them with a PUT request. The raw date format (before conversions by data.js) is as follows:

2012-04-30T11:15:59
i.e.
2012-04-30T11:15:59Z 
data.js converts this string to
Mon Apr 30 2012 13:15:59 GMT+0200 (CEST)

This is done in the methods

var parseDateTime = function (propertyValue) {...}
i.e.
var parseDateTimeMaybeOffset = function (value, withOffset) {...}
To the user I would like to present it this way (which works with chrome, but not Safari)

Monday, April 30, 2012, 13:15:59

I am able to do this in chrome by using the functions ot the javascript Date object I created with new Date();. However, in Safari it does not work which is due to the source format of the date. Safari can only handle the "raw date" format, chrome is a bit more tolerant I guess.

Additionally, I need to convert the nicely readable date format into the "raw format" again before passing it to the PUT request. Currently I am doing this by hand but am sure there is a better way. I also saw the odata.jsonHandler.recognizeDates property but since I use the atom+xml format this does not apply I guess.

Any pointers would be great.

Best regards,
Jan

May 3, 2012 at 10:43 PM

Hi Jan,

    DataJS parses the date strings in the OData payload and converts them into Javascript Date objects.  How the data object is displayed as a string then is browser and javascript engine specific (depending on how they implemented the Date.toString() method) and we don't have any control over that.  Now, regarding your two questions above:

    1. Yes, when using JSON for talking with the OData endpoint... by default, datajs will not try to convert date literal values in the JSON payload if it you don't pass a metdata object to OData.read / OData.request. This is because there is no way to determine that the value is actually a date and not a string that happens to be formatted as date..  There is a flag to turn on the interpretation of date literals into javascript Date objects.

    2. If in your request the property is a Date object, then datajs will serialize into a string following the ISO date format before sending the request to the server.  If the property happens to be a string value then the value will fly back to the server as string (there are some other things to keep in mind if you are passing a metadata object into datajs.... but I don't think it is the case here).

   Based on your scenario, what you are facing is a data presentation problem, not a data problem itself.. I would not worry too much about converting the dates back and forth from a format that OData likes... that's what datajs is for..  Your concern should be how to display the data in a homogenous way to the user.  There is a librarly called date.js  that seems to ease the pain of working with javascript date objects in different browsers..  It might help you here..  But what I would do is once I get the data back form datajs as a Date object then just have a function in your UI layer that displays the date object as you like .. you might even want to override the Date.toString() method to do so. 

Regards,

Alex Trigo.