Rules for OData datetime properties

[Former Member]

There have been quite a few posts about problems with Edm.datetime properties in entities. Solutions offered are often on case by case basis, so it's hard to figure out why things have gone wrong and what the remedy is.

This is a short discussion (I hope!) to establish some rules for edm.datetime properties. If there are any exceptions to these rules, or some addtitional rules, please post.

Rule 1

Use the Edm type datetime. Don't maintain dates as edm.string "for convenience"

Rule 2

Make the property nullable if a null value is possible. If there is a need for a value (mandatory) do not make it nullable.

Rule 3

The nullable attribute can only be correctly evaluated if the backend date contains '00000000' as a value. ABAP date values containing spaces (this is allowed unfortunately) will not be treated as null, but also not be able to convert to an edm.datetime - you will get a runtime error from the server.

Rule 4

Be aware of the full property definition. Giving your "date property" a type of edm.datetime alone is not enough to ensure proper conversion during OData parsing. See rules 5, 6 & 7.

Rule 5

If the date property is part of a DDIC structure used for the entity definition, and that component is a DATS (elementary D type), then you can place a D type value in it directly, e.g.

Valid ABAP:

     ls_entity-date = sy-datum.

Dates of this type can fall into the "date is null but not valid" trap mentioned in rule 3.

Rule 6

If the date property is not part of a DDIC structure and the entity definition is "freeform", you can also place a D type value in it directly if you assign its backend data typing: e.g..

Dates of this type can fall into the "date is null but not valid" trap mentioned in rule 3.

Rule 7

If the date property is not part of a DDIC structure, the entity definition is "freeform" and there is no backend data typing, the target must be filled as if it were a timestamp; this is because the MPC generated property type is a packed type field. In rules 5 and 6, the MPC generated property type is a D type.

Note that the edm.datetime will contain an additional portion representing microseconds, which is not normally filled unless drawn from a high resolution timestamp (i.e. more detailed than sy-uzeit).

Dates of this type cannot fall into the "date is null but not valid" trap mentioned in rule 3.

Rule 8

You may also use TIMESTAMP as the component type in a DDIC structure entity base instead of DATS. This can be converted as per rule 7.

I'm sure there are more things we can add here: for example, I found that "json format" feed dates can look a bit "odd" - are they right or wrong?

Regards

Ron.

[stefan_schreck · Accepted solution]

Hello Ron (and all),

Note that Edm.DateTime is not part of the V4 specification of odata.org anymore.

To anticipate V4, I recommend to use Edm.DateTimeOffset instead; this is already supported by NetWeaver Gateway.

Regards,

Stefan

[Former Member · Accepted solution]

Thanks Stefan.

Just when we think we've got to grips with the date and time options, it changes again!

Expect some additions to this page when OData 4 comes along then...

regards

Ron.

[RalfHandl · Accepted solution]

Hi Ron,

The only difference between DateTime and DateTimeOffset is that the latter contains time-zoned values, e.g. a trailing Z for UTC.

Without time zone sender and receiver need out-of-band information to correctly interpret the values. DateTime was defined to have an undefined offset, so we removed it from OData 4.0. Which wasn't an easy decision.

Regards!

--Ralf

[RalfHandl · Accepted solution]

If the ABAP data type is just a date (DATS) without time portion, you will want to use the new type Edm.Date once V4 arrives in your Gateway.

My recommendation: use Edm.DateTimeOffset for time stamps (here the time zone matters) and Edm.DateTime as a work-around for pure date fields. Additionally annotate the date property with sap:display-format="Date", see SAP Annotations for OData Version 2.0 | SCN. This will tell clients that only the date portion is relevant.

Regards!

--Ralf