From the user perspective it is not clear, what DateTime represents.

https://reference.opcfoundation.org/Core/Part6/v105/docs/5.1.4
https://reference.opcfoundation.org/Core/Part6/v105/docs/5.2.2.5
https://reference.opcfoundation.org/Core/Part6/v105/docs/5.3.1.6
https://reference.opcfoundation.org/Core/Part6/v105/docs/5.4.2.6
=> description defines implicit the DateTime as UTC, with plattform dependent resolution
=> XML creates as only one an exeption, that the value could be UTC or UTC with timezone information (in parallel to the servertype->localTime info). On the other side, JSON is defined ISO-8601-1...

https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11
=> defines implicit for ServerTimeStamp and SourceTimeStamp UTC values

https://reference.opcfoundation.org/Core/Part3/v105/docs/8.37
=> introduces a new subtype of DateTime for UTC values, what (by description in the other linked chapters) isn't necessary, because DateTime and exchanged values between server and clients are always UTC...

The problem with unsynchronized clocks (source / server / client) is independent from this problem.

So the questions to be answered should be

• What is the difference between DateTime and UtcTime (from the specitication, there isn't a difference visible)? If there is no difference -> remove the UtcTime datatype, because it introduces only friction (betweend developers) and miss-understandings.
• Add a clear remark, what DateTime is (UTC or not)
• harmonize the definition, so that timezone information is only available at one place (as defined by the ServerType) and doesn't create different specifications depending on the encoding (binary, json, xml)
• Add a link to DateTime description to the ServerType, so that a server should provide the LocalTime information (this dependency is currently only visible by digging specifications or a deep knowledge of OPC UA)