Interpret lsclocks output of system, rtc and ptp hardware clocks

Invoking lsclocks on a Fedora 43 output yields output like the following:

# date -Is; lsclocks | grep 'NAME\| realtime \|tai\|ptp\|rtc'
2026-08-15T12:55:39+02:00
ID NAME             TYPE                 TIME RESOL                            ISO_TIME
 0 realtime         sys  1786791339.653681241   1ns 2026-08-15T10:55:39.653681241+00:00
11 tai              sys  1786791376.653778750   1ns 2026-08-15T10:56:16.653778750+00:00
   /dev/ptp0        ptp  1786791339.176323013   1ns 2026-08-15T10:55:39.176323013+00:00
   /dev/rtc         rtc  1786787739.000000000       2026-08-15T09:55:39.000000000+00:00
   /dev/rtc0        rtc  1786787739.000000000       2026-08-15T09:55:39.000000000+00:00

What is ok:

• lsclocks displays all times in UTC (date prints by default under the configured CEST timezone)
• the tai clock is 37 seconds fast, because so far 37 leap seconds are officially announced for insertion

What surprises me:

1. The rtc clock running exactly 1h behind UTC (i.e. it has an offset of 60 minutes), although the system has chronyd running with rtcsync option (default on Fedora).
2. The PTP hardware clock (PHC) ptp0 being suspiciously closely aligned to the system clock, although no process (such as phc2sys) appears to be running that might actively synchronize it.

Regarding ptp0 - it's the PHC of the main ethernet interface, which is located inside a thunderbold docking station, ethtool -T links it to that interface and reports hardware timestamping capabilities. The kernel uses the igc (Intel) driver for that interface, which lspci reports as: Intel Corporation Ethernet Controller (2) I225-LMvP (rev 03)

The chronyd runs pretty much with default options, i.e. it doesn't have the hwtimestamp set - and even if it did, chronyd documentation states that it leaves the PHC free running, even if it uses it for relative timestamping:

chronyd does not synchronise the NIC clock. It assumes the clock is running free. Multiple instances of chronyd can use the same interface with enabled HW timestamping.

(chrony.conf(5))

So my expectation is that the PHC would be free-running, possibly being initialized once during boot to system time (by its driver) but afterwards drifting much away from system time. Or simply starting from 1970 after system boot.

What am I missing? How can I diagnose whether some process/the driver is synchronizing the PHC? And why isn't the RTC running on UTC?