I'm paraphrasing as this is way more complex, but originally the boxes would boot with a date which is the start of the unix epoch (1/1/1970). Vix log files would always be named with 1/1/1970 in the filename. There was code in enigma which checked the time to see if it had been set to something reasonable (much greater than 1/1/1970) before checking recording timers, power timers, epg load etc. etc. enigma essentially waited until a transponder sync or an NTP sync had been done. The process essentially "worked", although the log files always contained 1/1/1970 and some seconds in the filename, so it was tricky to distinguish one from another.
Fast forward to late 2017, when "fake hwclock" was implemented. This routine stores in a file the date/time the box is placed in deep standby. At startup, the file is read and the time is used to establish a "reasonable" date/time before an actual time is obtained from NTP or a transponder/multiplex stream. It's similar to the procedure used in Raspberry Pi models which don't have a realtime clock. Initially I thought that this was a great improvement over the old scheme as the log files now have a "reasonable" date and time in the filename, but I found an issue shortly afterwards (January 2018) on my test machine - a mutant HD51 connected via wifi. I was using NTP sync on that box and found it pushed the system time into the future on some occasions. I reverted to transponder time and it seemed to resolve the issue for a while. @birdman helped me greatly over that period and we tried various tweaks to get my NTP syncs to work reliably without success. In the end, I just disabled the "fake-hwclock" script entirely and reinstated NTP sync. I occasionally get log files with 1/1/1970 date, but 95+% of the time, the logfiles are correctly named and 100% the enigma code always waits for a proper time sync before testing for record timers, autotimers etc.
The thinking behind running ntpdate at startup, I believe, is that ntp will provide a more reliable system time than depending on a transponder time value. On 28.2E the transponder data is mostly very accurate. Other satellites and DVB-T systems may not be so reliable.
The way ntpdate works is by examining the current system time and comparing it to the time received from the NTP server. It calculates the difference in the two values and either "steps" the system time immediately by the difference in value, which results in a jump in the system time, or it "slews" the system time by the new value, which results in a gradual correction of the system clock by varying its frequency. Normally ntpdate would only "step" the time on first run (because the time difference is large) and would always "slew" the time subsequently.
Theoretically, ntpdate should run just once at startup and step the time. Then, it should run either every 30 minutes by default if set, and/or if a cron job to run ntpdate is present and active. In my case, I can see ntpdate running every 30 minutes after startup and also at 30 minutes past the hour, because a system cron job is active.
However, for some reason, ntpdate seems to be running twice in quick succession at startup and is using the stored "fake-hwclock" value as the system time in both instances and then stepping the clock twice. I don't know why this is happening, but it may be due to some recent change. The dev gurus will have to look at the code and startup sequences.
Not associated with the box but with a few minor "10 minute" DIY jobs taking hours 
