Hi,

There are 2 separate things I need to address.

1. There are no timezones “per se” in OPC UA. The OPC UA DateTime type is always in UTC, thus you must always give the data in UTC and handle it as UTC “SDK-wise”. How exactly that data is then visualized or constructed is up to you. Did you try with https://www.prosysopc.com/products/opc-ua-browser/ ? In general UIs typically might visualize the data in local timezone, but internally it is still UTC.

2. The com.prosysopc.ua.stack.builtintypes.DateTime class has a lot of … legacy, about 15 years I think. In my personal opinion, it is not very good in todays when compared to e.g. java.time.* APIs.

Longer explanations with a lot of personal opinions:

1.
DateTime is always transferred in UTC timezone: https://reference.opcfoundation.org/Core/docs/Part6/5.2.2/#5.2.2.5.

The com.prosysopc.ua.stack.builtintypes.DateTime holds the value also in UTC. “OPC UA Epoch” is “1601-01-01 12:00AM UTC” and the resoultion is 100s of nanoseconds from that. It is one of the things OPC UA “inherited” from OPC Classic. It is basically Windows FILETIME: https://docs.microsoft.com/en-us/previous-versions/aa915351(v=msdn.10)?redirectedfrom=MSDN.

The “Java Epoch” (or Unix Epoch https://en.wikipedia.org/wiki/Unix_time) is the more common in java based APIs. In java the resolution is typically milliseconds (or java.time.Instant has nanosecond resolution). Also, the data is “in UTC” or “timezoneless, but interpret as UTC” data, e.g. see System.currentTimeMillis.

2.
I would personally try to avoid using the com.prosysopc.ua.stack.builtintypes.DateTime directly, basically only use it if you do not have anything better (obiviously you need it to the API itself). If you are on Java8+ just use java.time.* in your application logic and just convert the data to DateTime whenever needed for SDK APIs. If you are on pre-Java-8 consider maybe consider https://www.joda.org/joda-time/ (though I have not personally used that, I believe it was what did lead to java.time being made).

Due to historical reasons, the DateTime class has APIs for both OPC UA and Java Epochs. Yes, it is a mess and can be very confusing. Anyway, regardless of which epoch, the data must always be given in UTC. In general, I would personally say it is a good idea in general to keep all “application data” in UTC and only visualize it in local timezones. The java.time.* has great tools for that (that is outside the scope of this answer however). One exception might be writing local-timezone-only-read files, but that is also outside of the scope.

If millisecond resolution is enough, you can use java.time.Instant.toEpochMilli() and static DateTime.fromMillis(long) + DateTime.getTimeInMillis().

Hopefully some day we can get rid of com.prosysopc.ua.stack.builtintypes.DateTime completely. Or just have conversion methods to/from Instant. In PubSubDataValue we used Instant, as it is in Java 8+ land, but the rest of the SDK is Java 6+ currently.