Quoting tuxd3v@??? (tuxd3v@???):

> problems with rtc clock are not uncommon, the need for a power
> cycle, seems to be..
>
> This discrepancies, in the date, .. how many days it takes to
> happen, does you have any Idea?
> does the Boards are properly powerup?I mean suficient levels of
> Voltage/Current..
>
> Try to update the date with something like 'ntpdate ntp_server_ip'
> And see is that helps, if yes then you can run it via a cronjob,
> from time to time..

If running ntpdate, depending on how much skew there is from correct
time, you might need the '-B' option. Quoting the man page:

       -B     Force  the  time  to always be slewed using the adjtime() system
              call, even if the measured offset is greater than +-128 ms.  The
              default  is  to step the time using settimeofday() if the offset
              is greater than +-128 ms. Note  that,  if  the  offset  is much
              greater than +-128 ms in this case, that it can take a long time
              (hours) to slew the clock to  the  correct  value.  During this
              time, the host should not be used to synchronize clients.

I should also mention that ntpdate being increasingly unmaintained and
crufty means that the 'sntp' or 'ntpd' utilities with appropriate options
are now better long-term tools.
https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

I think 'ntpd -gq' will do the trick. Or 'sntp -s <IP>'.

'ntpd -gq' will fail if the ntp daemon is binding to the service port,
but ISTR you can supply '-u' to work around that. (Above is from
memory, not tested.)