We double-checked and analysed the situation from CAP side, with these outcomes ....

Long story short:

1. The behavior in the New OData Adapter (NOA) in cds8 is correct; the former behavior in the formerly used OData lib was wrong.
2. We should definitely keep the correct one, and would strongly ask you to adopt the correct behavior in your clients (note that Fiori clients always behaved correctly).

Long story long...

1. The relevant CDS types are specified as follows (from the very beginning of CDS):

   CDS Type	Remarks
   DateTime	sec precision
   Timestamp	µs precision, with up to 7 fractional digits

   "second precision" means 0 fractional digits, of course.

2. The cds compiler maps the CDS types to OData as follows (always did so):

   CDS Type	OData v4
   DateTime	Edm.DateTimeOffset
   Timestamp	Edm.DateTimeOffset with Precision="7"

3. The OData standard specifies for Edm.DateTimeOffset attribute Precision:

   The value of Precision is a number If not specified for a temporal property, the temporal property has a precision of zero. ("temporal" in there means date/time related data)

4. The improved input validation in the New OData Adapter (NOA) corrects quite some glitches of the former external OData lib we used. One of which is checking on value and precision ranges of numbers and date/time values to protect applications from late data loss surprises due to unexpected truncation → was requested by many stakeholders/customers.

Does that help?