Arch Linux

Reproduction:
Let assume we have some system where hardware clock shows local time. You can create vmware machine for testing.
Boot from Arch CD (I used latest from tpowa, but I don't think that matters) and install Arch.
During install procedure ensure there is HARDWARECLOCK="localtime" in /etc/rc.conf.
Reboot system. On reboot you can go to BIOS to ensure that the time is still correct.
Now check the time. It will be incorrect.
Why? Because in some way Arch thinks that hardware clock shows time in UTC, and so it adds required timeshift to produce localtime and saves it in BIOS. But it's wrong, because hardware clock already was in localtime!
So, before install I had 14:xx, after install I have 17:xx. That's because my timezone is GMT+0200 and DST time adds 1 hour two - thus 3 hours total. I noticed this on dual-boot system when after installing Arch my Windoze showed me wrong time.

The strange thing is that this happens only on first run. So I examined /etc/rc.sysinit:

if [ "$HARDWARECLOCK" = "UTC" ]; then
/sbin/hwclock --directisa --utc --hctosys
else
/sbin/hwclock --directisa --localtime --hctosys
fi
if [ ! -f /var/lib/hwclock/adjtime ]; then
echo "0.0 0 0.0" > /var/lib/hwclock/adjtime
fi

and /etc/rc.shutdown:

if [ "$HARDWARECLOCK" = "UTC" ]; then
/sbin/hwclock --directisa --utc --systohc
else
/sbin/hwclock --directisa --localtime --systohc
fi

You can see why this time change happens only on first run. Because /var/lib/hwclock/adjtime does not exist at that time. It seems that "/sbin/hwclock --localtime --hctosys" behaves wrong without /var/lib/hwclock/adjtime.
I think generating /var/lib/hwclock/adjtime during install will solve this problem.