I dont know if this topic is still a point for you but maybe can be good for someone else that notice the same issue.
So my observation is based on ABB Automation Builder Simulation Mode and it is as following;

Timer functions that are based on system time has limitation like 35 minutes 47 seconds 484 mseconds and 416 useconds. (SysTimeGetMs(), TON, e.t.c)
As you self answered when the overflow occurs because of the biggest interval, this memory address is resets to 0 without any problem, so you dont need to worry if your timer interval is smaller than ~49 days.
But in the simulator that i run it behaves differently than the real hardware plc. So I can only here express my observation related to the simulation mode.

For an alternative approach to overcome this problem in simulation mode can be as following; I have used RTC as below;
Another side effect of the timer is that as long as you start the simulation it starts to measure time and the memory address is getting closer and closer every minute to that overflow point which is ~35 minutes. So you could only test your program if you use timer 35 minutes than the only way is to close the abb automation builder and start it again. On the other hand this behaves differently at codesys 3.5 in simulation mode it has ~49 Days limit and I did not try to test it actually if it resets itself in simulation mode as expected.
--------------------------------------------

VAR
dwErrorCode:DWORD;

rtNow:UDINT;
END_VAR

rtNow:=SysTimeRtcGet(pResult:=dwErrorCode);

--------------------------------------------
With RTC I did not observe any issues. So UTC epoch time was my alrenative workaround for this problem.

With additional logic one can measure the required time interval and get the necessary actions in the program.