I should have mentioned that I am in the America/New_York timezone and TIMEZONE is set accordingly in rc.conf.

What exactly the bug is? Have you tried using UTC for both Arch and Windows?
You should use the forums to try to fix things first and post a proper bug report only if you find a bug.

Karol -- the bug is as I described: I am getting the superblock timestamp errors on every reboot, as I mentioned in the original bug report.

Yes, I have tried using UTC for both Arch and Windows (editing the registry to convince Windows to understand that the hw clock is UTC). In fact, I am running the system that way now. If you are implying that that is a way to work around the problem, that's true. But that doesn't negate the fact that there is an issue here with the handling of localtime.

As for your last sentence, your little lecture about bug-reporting protocol, of which I am well aware, I did precisely that and there was an awful lot of discussion of issues like the one I encountered, but nothing helpful that I was able to find.

Sorry for the delay in dealing with this.

Do you use the "fsck" hook in your mkinitramfs? If so, this report should be assigned to Dave (I'll assign it preemptively).

Assuming you don't use the fsck hook:

Do you get a message saying "Adjusting system time and setting kernel timezone" during boot (check /var/log/boot)? Add an "echo $HWCLOCK_PARAMS" before "unset TZ" in rc.sysinit to check if the correct timezone is being set.

I should add: we never test with RTC in localtime, and we don't really support it (as it is known to be broken in unfixable ways). That said, if we can fix this then of course we will.

One more piece of info: could you please paste the contents of your /var/lib/hwclock/adjtime ?

Before answering your questions, I want to mention something I observed very recently. I've seen this behavior on a couple of machines, most recently on my Toshiba netbook, an NB305, with Arch installed together with the Windows XP that came with the machine. I booted Arch and noted that the time was incorrect -- 4 hours too late; in other words, UTC. I checked /etc/rc.conf, and HARDWARECLOCK was/is set to "localtime" and TIMEZONE was/is "America/New_York". I corrected the date/time with 'date' and then did a hwclock -w and rebooted. The clock was still wrong, 4 hours too late!! So rebooted, went into the bios setup, and the hardware clock was, indeed, 4 hours too late and so I fixed it there. I then rebooted Arch, and the time was correct. It looks to me like hwclock failed (silently -- I got no error from it) to set the hardware clock.

One comment about your last message: if you "don't really support" localtime and don't test it, then, in my humble opinion, you shouldn't offer it as an option. I do of course appreciate your willingness to try to fix the problem, but if the option is there, it ought to be supported and tested. And I would argue that it should be supported, since, unfortunately, the world is littered with instances of Windows XP, as is the case with my netbook, and XP does not support UTC correctly. I have other machines with ARCH installed next to Windows 7, and in those cases I use UTC, since Windows 7's UTC support works correctly.

Ok, your requests:

1. I'm not sure how to check your query about a fsck hook in mkinitramfs. If you could be specific about how to get you the info you want, I will do it.

2. I do get the "Adjusting system time ..." message while booting. As for checking whether the correct timezone is being set, I'm curious why that matters. If the system time is local time, then during normal operation, the system doesn't need to do timezone corrections, if I understand correctly how timekeeping works. Also when I use the 'date' command, the response I get includes 'EDT', which I would take as proof that the timezone is correct. If you disagree and still want me to stick the echo into rc.sysinit, let me know and I'll do it.

3. /var/lib/hwclock/adjtime:

24.942066 1336362521 0.000000
1336362521
UTC

We might remove the option for localtime in the future, but as you point out, there area people who use it. Currently it mostly works, but since we know that it can never fully work, no one have been motivated to work on it. The reason it can not work is that time is monotone and continuous, but 'localtime' is neither (due to daylight saving). Aside from this mismatch with reality, we have a technical problem that the kernel uses the RTC during early boot, and unless we want to compile ask the (rapidly changing) timezone data into the kernel, this can only work with the RTC being in UTC.

The way it currently works is that time is first set to UTC, then it 'jumps' to localtime (which might cause weird things to happen), if on top of this a daylight time change has happened since last boot, it is any ones guess what the real time is (since we have no way of knowing, we assume the admin sorts this out manually.

As to supporting this going forward, we basically need someone who understand how it all works, and who uses localtime and who uses testing to keep an eye on things.

To your problem: adjtime says that your RTC is in UTC, which is causing some confusion at done point (not sure where, add I'm on my phone and can't check the code). This can be fixed by either editing adjtime manually or calling hwclock with the right parameters. 'man hwclock' will give the details.

I think I'll add a warning to initscripts when this situation occurs (rc.conf and adjtime differing). Thanks for your report!