Skip to Content
9
Former Member
Oct 21, 2013 at 03:32 PM

Rules for OData datetime properties

16078 Views

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.

Attachments