There is already a thread on this for the 5.12 firmware, but seems to be falling a deaf ears.  It is appreciated that many suggest dropping the Hardware controller and using a software controller instead, but whether this is possible or not, the underlying problem is the hardware controller does not properly synch the time as would be expected of any decent network management controller.  It could also be viewed that the TP-Link has hard coded a time server ignoring the settings made through the portal.  Regardless, there seems to be no attempt by the controller to re-initiated a synch if it doesn't receive a response from the time server when the Hard Coded schedule is reached, and doesn't attempt to synch if the controller is powered off at the scheduled time either.  

In the scenario that this is higlighted to the point of unusability, the network is setup in an area with unreliable power, and uses Starlink for internet connectivity which also has the occasional drop, mainly due to weather.  The portal is critical to providing controlled access to the internet and the local network facilities, thus a local controller is essential.  This time issue raises its ugly head when - the power is out (which can be for hours) the time reset to a random date/time in the past (there is no understandable commonality in the reset date/time).  when it comes back online, the controller doesn't seem to bother in re-synching its clock to the timezone set (unless it tries only once, but if the internet is not available, just doesn't try again).  Once it reset, any and all logs that from the time after the new date, are gone.  On one occasion the system was down for a few hours overnight, after being up for 12 days, logging user access and network usage, once the power failed it reset to a month previously and all the logs were gone for the period in between.

Reviewing the time synch options for other brands like cisco, uniquiti, netgear, huawei and even mikrotik, they all have settings to adjust the frequency of time synch, and always retry if there is a connectivity issue that has affected the time synch.  this is even programable in IOT devices, so it seems a fundamental flaw in the Omada Controller program.  even having a forced minimum synch frequency would be better than nothing, as it seems the later is the case and the assumption is that there will always be conectivity and no power outs.

I hope, rather than replies just suggesting to use the software controller or other, lets focus on the actual problem in the device, and not a work around.