unggnu: That is not actually true in general; you seem to be generalising from your own experience and assuming that that's what the installer does in all situations, which is not sound practice. As for why we prefer UTC if possible, there are many good reasons why storing the hardware clock in local time is fundamentally unreliable and cannot be made reliable; Markus Kuhn makes the case in http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html much better than I can, and I encourage everyone with an interest in this area to read and digest that article. We only reluctantly use local time on systems believed to be already storing the hardware clock in local time because that's the only way to achieve at least minimal cooperation (even though it's unreliable) with other installed operating systems.
Everyone, but especially unggnu: please, please stop marking bugs about this issue in general as duplicates. One thing that is actively making it difficult for us to track down all the causes of this and fix them independently (for there is more than one cause of this problem!) is people piling onto bugs and assuming they're the same basic thing. It would make it easier for us if people worked on the assumption that all instances of this bug are independent until proven otherwise. So far, we know of at least the following independent causes of this type of problem: 1) various bugs that existed before Karmic (http://wiki.ubuntu.com/HardwareClock was the result of our last in-depth analysis of this class of problem); 2) this issue with the alternate CD installer (d-i), which Christian has described accurately in comment 1 and which is on my list to fix for Karmic; 3) bug 431786 (fixed), which was a similar issue with the desktop CD installer, although the ordering is quite different there and so the fix was independent; 4) bug 427822 (fixed), which was a problem with the behaviour of the ext3/ext4 filesystems when replaying the journal at mount time, particularly relevant when mounting the root filesystem before we've had a chance to adjust the system clock properly; 5) a further conjectured bug in ext3/ext4, in which the clock is just plain incorrect (due to user error, clock drift, etc.) and is corrected by NTP or user action after filesystems are mounted, but the corrected time is not written back to the superblock on unmount. ... and this is just what we've come up with so far! Unless you are able to perform an accurate in-depth analysis of the problem, therefore, please do not mark bugs such as this as duplicates, and if possible we would also greatly appreciate the waters not being muddied in comments, as it really does make it more difficult for us to put all the pieces together. ** Package changed: debian-installer (Ubuntu) => clock-setup (Ubuntu) ** Also affects: clock-setup (Ubuntu Karmic) Importance: Undecided Status: New ** Changed in: clock-setup (Ubuntu Karmic) Status: New => Triaged ** Changed in: clock-setup (Ubuntu Karmic) Importance: Undecided => High ** Changed in: clock-setup (Ubuntu Karmic) Assignee: (unassigned) => Colin Watson (cjwatson) ** Changed in: clock-setup (Ubuntu Karmic) Milestone: None => ubuntu-9.10 -- Installer (alternate-CD) saves wrong time in RTC https://bugs.launchpad.net/bugs/440281 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
