Hi,

It is per se not possible to “change the timezone of the OPC UA Server”, because there is no such concept in OPC UA (but do read the whole post, in theory maybe there is, but realistically not or like it doesn’t affect anything).
The server always “runs” in UTC and the DateTime DataType always represents the timestamp in UTC when it is transferred in binary between the client and the server. Yes, there is the type https://reference.opcfoundation.org/Core/Part3/v105/docs/8.37 “UtcTime”, but I do not understand thy this type exist since base type of this ‘DateTime’ is already UTC https://reference.opcfoundation.org/Core/Part6/v105/docs/5.2.2.5. Even the UtcTime also says “All time values conveyed between OPC UA Servers and Clients are UTC values. Clients shall provide any conversions between UTC and local time. “. It is possible this is something historical and the type ‘UtcTime’ probably cannot just be removed.

I have limited information, but as far as I’m aware, no-one has ever used the TimeZoneDataType.

In short I do not know what use the ‘SetMachineTime’ does have with that. Maybe the makers of EUROMAP have made a mistake and do not know the above?
Or maybe the timezone is just an extra information, but it wouldn’t like affect at all any time “set by the method”, because that parameter (I assume) is still something DateTime-derived and thus always in UTC (because any simpletype is transferred as the base type rules, thus they must also be in UTC).

I guess it could be of some use to know which timezone the server runs, but it doesn’t affect at all to the timestamps provided by the server. Or I guess in theory IF types derived from String would be used (https://reference.opcfoundation.org/Core/Part3/v105/docs/8.42 or https://reference.opcfoundation.org/Core/Part3/v105/docs/8.46), but I have not seen them ever used.

Note that if you would “set the time of the server”, this would mean setting the time of the Operating System of the machine. And I think probably the timezone as well in the OS level. We do get the time from the system clock.

Changing the clock time on the server could have some implications temporarily, e.g. some java timers do not work that well if the clock “jumps” and may exec really fast temporarily to exec as many times as-if they should have if the time would have flow in a constant manner. Also it might suddenly expire Sessions, SecureChannels and Subscriptions via lifetime-timeouts. In the worst case, it could immediately make a cert unuseable if the clock jumps like years. And I think there was also some requirements that the clocks should be somewhat synchronized when using security, thus, it should be more likely that you run e.g. ‘NTP’ or something that will keep them in sync instead.