Invalid date/time

[sonjadeissenboeck]

My issue

In my local environment, I can without any issues consume date/time values in my UI. However, once I deployed my app to the BTP CF-Environment, once opening any UI that consumes date/time values, I get an error saying The following problem occurred: Invalid date/time value - sap.ui.model.odata.v2.ODataModel. In the batch request, I can see that date values are received like this: /Date(1661558400000) and the time values like this: PT14H00M00S. In the deployed postgres database they are stored like this: 2024-06-24 23:26:31.968 +0200, or time: 09:30:00. Obviously, the format is somehow breaking, because if I understand correctly, odata v2 is processed/consumed differently than odata v4. Found this blog post on this.

Is this known? And are there any workarounds?

Details about my project

Customer Project	non-public repo
Node.js version	v19.9.0
@sap/cds	7.9.2
@sap/cds-compiler	4.9.4
@sap/cds-dk	7.9.3
@cap-js/postgres	1.8.0
@cap-js-community/odata-v2-adapter	1.12.10
OData version	v2

[oklemenz2]

The OData V2 Adapter relies on the OData V4 service. As you use Postgres, I guess the OData service based on Postgres behaves differently that the one based on HANA or SQLite. Do you use SQLite locally? That would explain why it works locally. The mentioned Date/Time formats are correct for OData V2 and are converted to OData v4 Date/Time formats in CDS OData V4 Adapter.

I have not tried Postgres with CAP, need to give it a try to say what’s wrong. Is the error occurring in UI only, or is there also a Backend error? Is it occurring during read or write?

How does the data look in OData V4 format? Is it correct according to specification?

[sonjadeissenboeck]

Locally I am also using postgres, which is why I am a little confused about the different behaviour.

The error is occurring in UI only, yes, the backend is not showing any errors on the GET request. During POST requests, I haven't seen the error yet. Directly accessing the service via e.g. Postman is working for GET as well as POST requests. So I really assume that the problem is the binding/consumption in the UI.

The OData format in v4 looks like this: for date"": 2022-08-27, for time: 14:00:00 and for timestamps**: 2022-08-24T15:23:23.FF3Z, so yes this is correct according to the specification.

Please let me know if you need any further information! :)

[oklemenz2]

This all looks correct, from my perspective. I also do not understand, that local it does work with Postgres and remote it does not work:

• Do you use different UI5 versions locally and remote?
• Do you use different Postgres version locally than remote? Of course, something MUST be different either in $metadata or in data
• Which Postgres version do you use?
• Do you see a difference in the generated $metadata document (diff)
• Do you see a different in the OData GET data (diff)
• Can you try to connect locally to the remote Postgres... Does then the error occur as well locally?

[BobdenOs]

timestamps: 2022-08-24T15:23:23.FF3Z

@sonjadeissenboeck the timestamp doesn't look correct it should not be FF3 it should be 23.000Z. This should be related to the Postgres version as FF3 support was added in Postgres 13 (docs).

[oklemenz2]

I close this issue, as it is not CDS OData V2 Adapter related. The Timestamp is not correctly coming from your deployed Postgres version.