systemd is said to not support localtime (according to archlinux wiki at least). But all default targets, like hwclock-load.service invoke hwclock without specifying --utc option, assuming that --utc will be used implicitly. But if this is not the case, this will lead to shifts in local time on every boot. hwclock man says: If you specify neither --utc nor --localtime , the default is whichever was specified the last time hwclock was used to set the clock (i.e. hwclock was successfully run with the --set, --systohc, or --adjust options), as recorded in the adjtime file. If the adjtime file doesn't exist, the default is local time. Hence, if user has no /etc/adjtime file, hwclock the most likely will use --localtime option implicitly. Solution: specify --utc option explicitly in all operations with hwclock.
I think this is mostly a misunderstanding. The place to configure UTC/LOCAL is the 3rd line in /etc/adjtime. If you don't have that file, create it. We support localtime in RTC just fine, in fact the whole hwclock-load.service exists only to support localtime, since the kernel can do UTC for you anyway and implicitly. If the archlinux wiki claims otherwise, then it is simply wrong and should be corrected. Basically, I recommend embedded folks and those not needing windows compat to simple remove the hwclock-load.service and leave the kernel do its job. And even if you need windows compat you are probably better of setting the RTC to UTC and teaching windows by some registry key to deal with it. localtime is fucked up, but we do have to support it, and we do just fine, if you configure this in /etc/adjtime.
Thanks for explanations, Lennart Poettering. I will initiate archlinux wiki editing to eliminate this misinformation. Should I close this ticket as a reporter?
I already closed it, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.