Incorrect system time after suspending

when i start my system (hp spectre x360) after suspension. the system time is usually incorrect. i’ve recently reinstalled my system, after this reinstall it started showing this behaviour which it didnt before.
If i run sudo hwclock -s the time gets corrected until i suspend again. if automatic time sync and automatic timezone are on this behaviour still occurs.
edit: i’m not 100% certain this only happens after a system suspends or if it always happens. but but after a start after suspension is usually when i notice it

What is the output of timedatectl?

               Local time: Wed 2023-04-19 12:14:41 CEST
           Universal time: Wed 2023-04-19 10:14:41 UTC
                 RTC time: Wed 2023-04-19 10:14:46
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

i saw the warning and changed timedatectl set-local-rtc 0. but the system then still shows the incorrect time and hwclock -s doesn’t fix it anymore
edit: the universal time is actually the correct time for me @computersavvy

the time difference has now gotten even worse

youpie@fedora ~> timedatectl
               Local time: Wed 2023-04-19 17:00:08 CEST
           Universal time: Wed 2023-04-19 15:00:08 UTC
                 RTC time: Wed 2023-04-19 15:01:53
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: yes

i dont see the correct time located anywhere( 1pm)

that seems to fix it, thanks. I dont know why tho haha

This shows that the system clock (RTC) is not set to UTC. It appears for your local time to be 1 pm, that the UTC/RTC settings should be 11 am (11:00) but the above shows 15:00, or 3 PM, which would throw everything off by 4 hours.

Are you sure that the time should show as 1 pm local time? If so then the RTC setting seems off by quite a bit.

after a quick restart the problem is back, yes when i wrote that post the time was actually 1 am.
if i run timedatectl again this is the output

               Local time: Thu 2023-04-20 10:49:09 CEST
           Universal time: Thu 2023-04-20 08:49:09 UTC
                 RTC time: Thu 2023-04-20 08:49:11
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

the current time is 8:49, not 10:49. although the rtc seems to have corrected itself. I really don’t understand why it says the universal time is my time and then just adds two hours to it. Does the NTP server respond with the incorrect time or something?

This error seems to be originating in the bios. When you enter the bios setup what time does it show?

If the bios time shows as local then it may explain all the angst. Bios should be set to UTC and that is the first place to look for this type of issue. Once the bios time is correct then the rest can be worked on within the OS.

When difference between the system (UTC) setting and NTP time is mismatched by more than a few minutes the system is unable to synchronize times.

I see that in post #2 above your system said the RTC was set to local time. Since that was 2 hours off from UTC and so far you have not stated that it has been reset to UTC I am leaning toward the need to reset the system (BIOS) time to match UTC (which can only be done within the bios setup).

The RTC clock should be set to two hours earlier that your wall clock time. Then the NTP can keep the clock in sync with the time servers.

When the kernel wakes from suspend, it has the set the current time from the RTC clock, and perhaps it assumes that the RTC clock is in UTC time. At least that was the case several years ago.