Aprende en Comunidad
Avalados por :
Understanding Date and Time Handling in SAP Gateway Foundation for OData Conversions
- Creado 01/03/2024
- Modificado 01/03/2024
- 35 Vistas
0
Cargando...
In a first blog post regarding conversions in SAP Gateway Foundation we discussed their relevance in the context of the differences between the ABAP type system and the OData type system. Although not directly related to conversions the handling of date and time perfectly fits into this topic.
ABAP knows date, time, and different representations of time stamps. And, it provides reuse functions to execute date and time calculations. OData has its own date and time definitions with functions that may be used in
Often, questions arise how the different representations map and how a data provider needs to be implemented to create a best match between both worlds. It is certainly not possible to dig into each and every detail. But, let us start with a few aspects.
To represent date and time information, the OData specification in version 2.0 knows the three primitive types
Since this is not really sufficient for business applications specification version 4.0 switches to
We focus on specification version 2.0 and restrict the discussion to Edm.DateTime and Edm.DateTimeOffset. Details regarding the representations can be found in the OData specification , the ISO 8601 standard , and in http://www.w3.org/TR/xmlschema-2 . Here, we quickly list the different formats. The literals are used in the URI, that is, in
Edm.DateTime represents a date and a time in UTC (formerly, Greenwich Mean Time):
The ticks in the JSON representation may also be negative to describe dates and time before Jan 1, 1970. "\/Date(-6847804800000)\/" is midnight Jan 1, 1753, for example.
Edm.DateTimeOffset adds time zone information relative to UTC. The date and time information is amended by the standard time difference (offset) with the sign v : +01:00 for Central European Time (CET) or -05:00 for Eastern Standard Time (EST), for example.
ABAP knows date, time, and different representations of time stamps. And, it provides reuse functions to execute date and time calculations. OData has its own date and time definitions with functions that may be used in
$filter
expressions, for example.
Often, questions arise how the different representations map and how a data provider needs to be implemented to create a best match between both worlds. It is certainly not possible to dig into each and every detail. But, let us start with a few aspects.
Date and Time in OData
To represent date and time information, the OData specification in version 2.0 knows the three primitive types
- Edm.DateTime,
- Edm.Time, and
- Edm.DateTimeOffset.
Since this is not really sufficient for business applications specification version 4.0 switches to
- Edm.Date,
- Edm.TimeOfDay,
- Edm.DateTimeOffset, and
- Edm.Duration.
We focus on specification version 2.0 and restrict the discussion to Edm.DateTime and Edm.DateTimeOffset. Details regarding the representations can be found in the OData specification , the ISO 8601 standard , and in http://www.w3.org/TR/xmlschema-2 . Here, we quickly list the different formats. The literals are used in the URI, that is, in
$filter
expressions or key predicates, for example. ATOM and JSON refer to the content type of the request or response payload. The number of decimal places available for sub-seconds is defined by the facet precision.
Edm.DateTime represents a date and a time in UTC (formerly, Greenwich Mean Time):
| Representation | Example | |
| Literal | datetime'yyyy-mm-ddThh:mm[:ss[.fffffff]]' | datetime'2016-07-08T12:34:56' |
| ATOM | yyyy-mm-ddThh:mm[:ss[.fffffff]] | 2016-07-08T12:34:56 |
| JSON | "\/Date(<ticks>)\/"<ticks> = number of milliseconds since midnight Jan 1, 1970 | "\/Date(1467981296000)\/" |
The ticks in the JSON representation may also be negative to describe dates and time before Jan 1, 1970. "\/Date(-6847804800000)\/" is midnight Jan 1, 1753, for example.
Edm.DateTimeOffset adds time zone information relative to UTC. The date and time information is amended by the standard time difference (offset) with the sign v : +01:00 for Central European Time (CET) or -05:00 for Eastern Standard Time (EST), for example.
| Representation | Example | |
| Literal | datetimeoffset'yyyy-mm-ddThh:mm:ss[.fffffff]Z|vii:nn' | datetimeoffset'1970-01-01T00:00:01+01:00' |
| ATOM | yyyy-mm-ddThh:mm:ss[.fffffff]Z|vii:nn | 1970-01-01T00:00:01+01:00 |
