Skip to Content
Author's profile photo Jerry Wang

Regarding Edm.DateTime in Fiori application

Recently I was struggled with a customer incident and finally I realized that I didn’t understand the Edm.DateTime quite clearly. So I spend some time to do research on it to fix my knowledge gap. I list my learning here in case any other guy needs it as well.

For my study, I use this field in my application for example.

/wp-content/uploads/2015/10/clipboard1_800886.png

It is bound to json model field “ClosingDate” with a formatter.

/wp-content/uploads/2015/10/clipboard2_800887.png

In the metadata, this field is defined with type Edm.DateTime (Represents date and time with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D.)

/wp-content/uploads/2015/10/clipboard3_800888.png

After I change the closingDate to 2015-10-3 and save the change:

/wp-content/uploads/2015/10/clipboard4_800889.png

The saved opportunity is reread from backend with an odata request. In Chrome network tab I observed the closingDate has this format: /Date(1443830400000)/:

/wp-content/uploads/2015/10/clipboard5_800890.png

What makes me curious is when I directly paste the url of the odata request to Chrome or SAP gateway client, I get the closingDate with this format instead. The figure below is response in Chrome:

/wp-content/uploads/2015/10/clipboard6_800891.png

And this is response from gateway client.

/wp-content/uploads/2015/10/clipboard7_800892.png

Why is there difference between them?

And when I type “alert(new Date(1443830400000));” in chrome console, I get this popup:

/wp-content/uploads/2015/10/clipboard8_800893.png

Actually it ( 2015-10-03 08:00:00 GMT +0800 ) points to exactly the same time as 2015-10-03 00:00:00 UTC.

So how could the date with format /Date(1443830400000)/ be consumed in my application?

It makes sense to start debugging via the framework handler when the response of odata request ( Opportunity re-read after closing date is changed ) is successfully returned:

/wp-content/uploads/2015/10/clipboard9_800894.png

check the body field:

/wp-content/uploads/2015/10/clipboard10_800895.png

The aim is to figure out how framework parses this /Date(1443744000000)/.

Then I reached the place:

  • there is a regular expression which extracts the number 1443744000000 from the input string.
  • a local time is returned by new Date(), with the number parsed by previous step passed in. The local time is returned based on current Time zone configured in my laptop.

/wp-content/uploads/2015/10/clipboard11_800896.png

Thanks to the framework, which has parsed the raw json response string to Javascript object, so that we application could directly use the converted object to bind our model.

/wp-content/uploads/2015/10/clipboard12_800897.png

Then the local time returned by framework will be passed into my formatter so now I could do any formatting based on customer requirement:

/wp-content/uploads/2015/10/clipboard13_800898.png

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jitendra Kansal
      Jitendra Kansal

      This value 1443744000000 is the date in miliseconds since Unix Epoch

      Author's profile photo Jose Antonio Ruz Polanco
      Jose Antonio Ruz Polanco

      This is a very interesting topic, even when I know is old, I will like to ask, If we need to send some date back in the URL of an OData Model read command, for a query, we would need to convert back that date to milliseconds?

       

      Author's profile photo Former Member
      Former Member

      Hi Jerry,

      Thank you for above information. It helped clearing my concepts.

      But I am facing an issue with the above method.

      Users from Chile(Timezone: UTC-6) are facing issue as they are getting one day previous date as compared to ECC dates.

      Can you please suggest what might have gone wrong?