Artix hwclock boot service vs NTP daemon: which should own clock synchronization?

Integration boundary

On Artix Linux, the hardware clock is applied at boot by an init-specific hwclock service (OpenRC, runit, s6, and dinit each ship their own script), while ongoing synchronization is handled by a separate NTP daemon such as openntpd, chrony, or ntp. The goal is a single, predictable owner for system time so that the boot-time hwclock adjustment and the NTP daemon's discipline do not fight each other.

Constraints

Because Artix ships without systemd, timedatectl is unavailable; the hardware clock policy (UTC vs LOCAL) lives in /etc/adjtime and the zone is selected by symlinking /usr/share/zoneinfo/<Region>/<City> to /etc/localtime. Service names and enable commands differ per init and are not interchangeable, so any guidance must be stated per init system. There is also a dual-boot dimension: with Windows present, the hwclock mode choice interacts with whichever daemon later adjusts the clock. Exact service script names may vary between Artix releases and should be confirmed against the installed system.

Questions

• Should the init's hwclock service only set the clock once at boot, with the NTP daemon owning all later adjustments, or is running both considered safe on Artix?
• Does the recommended ownership split differ between OpenRC, runit, and s6, given their different hwclock service implementations?
• When dual-booting Windows with /etc/adjtime set to LOCAL, does the NTP daemon need any different handling than in UTC mode?