Hardware and system clock gets offset by roughly 7 minutes on each boot although locale and time zone are correct

If you have a larger time difference between the real time and your RTC as you have when booting, you can configure NTP to over compensate for that in one go after start, instead of doing it slowly and incrementally over time.

I would add to your /etc/ntp.conf file as the first line (it has to be the first line):

tinker panic 0 

tinker panic - Specifies the panic threshold in seconds with default 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted.

Whilst this may solve the Linux time problem in the present, I would also investigating over time the underlying causes of the time drift between the two OSs.

Since the timedatectl command reports that the "Universal time" (i.e. the kernel's idea of UTC) and "RTC time" are in sync, the real-time clock is in UTC time and the time has been successfully transferred from the RTC to the kernel clock at boot.

But the System clock synchronized: no would indicate that ntpd is not successfully syncing, possibly because the difference between the real UTC and the system's idea of UTC is too great. Rui F. Ribeiro's answer was aimed to fixing that.

You should check the contents of the /etc/adjtime file. The first line should contain three values, separated by spaces. The first is the assumed systematic drift rate of the battery-backed RTC, in seconds per day. The second value is a UNIX timestamp of the most recent time the RTC was adjusted for drift.

If the drift rate is erroneously large (possibly because the RTC was adjusted by another OS while it was running, which was misdetected as RTC drift), it might cause the 7-minute error at boot.

Since the drift rate correction is applied at boot time when the time is copied from the battery-backed RTC to the kernel clock, any error caused by an incorrect drift rate can be propagated to the kernel clock too. That would explain why both clocks are in sync with each other while being 7 minutes off real UTC. It also means running hwclock --hctosys would not fix the problem.

if the drift rate in /etc/adjtime is abnormally large, you should set it to zero or even wipe the entire file, to stop the incorrect drift rate correction from adjusting your clock. If the system clock is going to be synchronized with NTP, it will normally propagate the synchronized time to the battery-backed RTC too.

If you want to set /etc/adjtime to automatically compensate for "cold" drift rate (i.e. drift that happened while the system was down or running another OS), then you could use the following procedure:

1.) Review your startup and shutdown scripts to ensure you understand all points where system clock or the battery-backed RTC is operated.

2.) Pick a time when the system will be down for a relatively long time (minimum 4 hours; overnight or over the weekend would be better). Then temporarily disable all automatic NTP synchronization. Make sure initramfs scripts are covered too.

3.) Just before shutting down the system, make sure the system clock is in correct time, then run > /etc/adjtime; hwclock --systohc --utc --update-drift. Verify that /etc/adjtime now has 0.0 as the first value of the first line, and the current Unix timestamp as the second value of the first line + as the only value on the second line, and the third line says UTC. Then shut down the system.

4.) After starting up the system again, use ntpdate or some other method that only sets the kernel clock to get the system to accurate UTC time. Then run hwclock --systohc --utc --update-drift again. Now the first value in /etc/adjtime should be updated to match the rate the RTC drifted while the system was down.

5.) Then make sure no startup/shutdown/cron job runs hwclock --update-drift automatically; on a NTP-synced system you would only want to update the drift rate when you know for sure nothing has adjusted the RTC over the time period you're using for drift rate estimation.

6.) Finally, re-enable NTP synchronization. If you dual-boot with two or more OSs, ideally only one OS should be doing adjustments to the RTC; otherwise drift rate estimates will be inaccurate.

I haven't checked for recent Linux kernels, but older ones had a very odd code to update the RTC from the system time (in RAM). Many years ago I had tried to fix that, but that code never made it to the kernel.

I think current systems update the RTC from system time on shutdown or reboot (if enabled).

If your distribution does not provide a mechanism, you could add a cron job (or systemd timer) to update the RTC periodically.