https://www.youtube.com/watch?v=2qB0aFzCQyY
If you set the PLC time using your
local time but
before fixing the time zone from UTC+1, and then the PLC
system time (RD_SYS_T) was off by 1h, but you never noticed because you were on DST so the DST offset may have canceled the system time offset. When you then fixed, per @mk42's comment, the time zone to be UTC+0, you lost the offset. Or summat like that (I think I am saying the same thing that @mk42 said about six posts ago).
Anyway, if that is what happened, then the example Hegamurl experienced (or arranged for purposes of explanation) in the video above is essentially the same situation you are experiencing, and you should be able to fix it the same way he did.
Bottom line: there is one base time in the PLC, and that is the system time. RD_SYS_T reads that time with no correction for time zone or DST. RD_LOC_T is an offset from system time that uses time zone and DST. When you set the time, via either from the PLC or by manually entering a time, in the [Set Time] window of the online diagnostics ([Online Access] => [DisplayLink Network Adapter ...] => [time of day.profinet...] => [Online and Diagnostics] => [Functions] => [Set time]), I suspect the online diagnostics interpret the entered time as a
local time, and use the curent time zone and DST settings in the PLC to back-calculate a
system time, and then use that back-calculated value to update the PLC system time. It's all about the bookkeeping.
Sidebar/thought experiment: if we assume that last paragraph is an accurate reverse engineering of the PLC time system, then what happens if we update the time on the PLC halfway between 2am and 3am local time on the day when the clocks fall back? How would the PLC know whether it was the local 2:30am before the change or the local 2:30am after the change?