I know this isn't a full answer, but also too much for a comment - I hope it might still help you.
If you want to go all-in you need to check which clock actually changes as there are multiple and most of them are stacked delta on top of the other.
For example if you are now after the one that is controlled by clock_settime as used by e.g. the date command to set time you could consider tracing any invocation of that system call via ftrace.
But that might be a bit too much, most commonly "time changes on network change" is due to DHCP being allowed to push ntp server information to a system. If it now happens that your openvpn connection might run dhlient (uncommon but possible) or has set explicit option to push info through dhcp it might happen that you get a nameserver set that does cause your system to change time.
In general checking ntp configuration like timedatectl timesync-status and/or chronyc sources (if you have it installed over systemd-timesyncd) changes pre/post openvpn dial-in would be a great start.
If it does the place I'd debug first, if it uses something like dhclient directly you can - for example - disable the ntp options in /etc/dhcp/dhclient.conf which will make the client not asking for those anymore.
The whole problem has too many "what if" and "it depends" to create a perfect answer. But maybe this gives you enough to add more detail to the question in the first place :-).
