The https://reference.opcfoundation.org/Core/docs/Part6/#5.2.2.5 says for DateTime (Btw, as the time of writing this, the link actually shows me the top of the page, not the section):
"...
Not all DevelopmentPlatforms will be able to represent the full range of dates and times that can be represented with this DataEncoding. For example, the UNIX time_t structure only has a 1 second resolution and cannot represent dates prior to 1970. For this reason, a number of rules shall be applied when dealing with date/time values that exceed the dynamic range of a DevelopmentPlatform.

...

A decoder shall truncate the value if a decoder encounters a DateTime value with a resolution that is greater than the resolution supported on the DevelopmentPlatform.
..."

That by itself is good and clear to me. However, what is not defined is how this affects things when the DateTimes are used within DataValue. The DataValue contains the 10s of picoseconds fields in addition to the DateTime fields and this provides scenarios not defined in the specification:

1. IF a DevelopmentPlatform cannot support full range of DateTime, that should to me indicate that a decoder can/must simply skip the picoseconds (like, they do not exactly make sense, since the Datetime itself was already truncated). However this is not defined (as far as I can see) in the spec.

2. IF a DevelopmentPlatform can support full range of DateTime, but cannot for the 10s of picoseconds? The specification doesn't say anything regarding this, but what if the "resolution of time" on a DevelopmentPlatform is 1nanosecond. Thus e.g. a Client writing a DataValue with picoseconds included would receive the same DateTime back, but the picoseconds part would/could/should be truncated? If this is the case, the Part 6 section 5.2.2.17 should be modified to add e.g. "See section 5.2.2.5 for truncation of DateTime if a DevelopmentPlatform doesn't support full range. A Decoder is allowed to truncate the picoseconds values if the resolution of time it supports is between 100nanoseconds and 10picoseconds" or something like that.

P.S. the "DevelopmentPlatform" support is here taken to basically mean "whatever an SDK vendor choses to use", since every app via raw binary is able to receive the value, thus via raw binary, it "should be" always be possible to support full range, though it might not be as practical to use so the truncation rules are sort of a good thing so "native" types can be used.