Arch Linux

What was the time when you booted into the system? Was it correct?

The correct time (on the host machine) was 19:00 EET (UTC+2). After booting into the VM using the 2009.01-ftp-alpha LiveCD, `date' would return "Sat Jan 24 19:00:00 UTC 2009", which is normal since I haven't selected my timezone just yet.

I'll upload a video to illustrate my issue better. :)

No i mean when installation was finished. What was the time in the newly created Archlinux system? See  FS#12941  for my experience in a normal installation.

I tried to finish the installation but grub refused to install (couldn't find the root partition or something). I'll poke some more at it and maybe create a new ticket about that.

Btw, the grub issue was probably caused by  FS#12917 . Installation worked flawlessly after using a local copy of x86_64 [core].

@Grigorios Bouzakis, time is displayed correctly after booting into the newly installed system.

The only place it's displayed incorrectly is at tzselect's confirmation step. I can't see a way to fix this, maybe we should go back to dialog based timezone selection?

I've had this behavior in at least 2008.06, maybe even in earlier releases.
I agree this should be fixed but I don't consider it a showstopper for 2009.01
I'll look at it before the next release.

Same problem here. When you repeat the step "Set Clock", the time is displayed correctly at the 2nd time. So I think the problem is that HARDWARECLOCK is set too late, after running tzselect. Setting it before running tzselect should solve the problem.

I have a similar problem, in the installation i choose UTC (my hwclock is in UTC time), and it appears fine when the dialog appears. But if i reboot without installing arch, then the hwclock is changed for localtime, and i have to set it manually

Well, we will at least replace tzselect with a dialog (ncurses)-based alternative. something like http://projects.archlinux.org/?p=archboot.git;a=blob;f=usr/share/archboot/tz/tz;h=d7446ec04ad45812a5b939ea2d82cb86e55df66b;hb=c9266cc5f655c8dbe96b6063a026eadcbb4f0aec

There one sets the timezone first, and then the date stuff, so this will probably fix this issue too. stay tuned.

+1 for using a own dialog for timezones.

We should avoid each tool which changes the time during any selection - until we wan't to change it. tzselect for ex. changes the time when selecting a timezone (this is bad cause the hwclock and system time is mostly correct after a boot). Same when copying timezone files to /etc/localtime. But when one only set and export TZ with his timezone then the system time is kept and only displayed with correct timezone value.

2009.02 time/date setting (in installer) is IMHO better than 2008.06 (tzselect, "hardcoded" timezone was CDT IMHO), but not optimal. In 2009.02 timezone was UTC after boot which is IMHO optimal for all installations.

What times have we after booting the live/install ISO?
1) hwclock
a) BIOS datetime is correct and set to localtime, or
b) BIOS datetime is correct and set to UTC, or
c) BIOS datetime is not correct

2) system time (this is interpreted with the timezone, first with UTC)
a) date shows false time when 1.a is given (localtime vs. UTC). Could be corrected when setting/exporting TZ with correct value, but we should avoid using tzselect or copy a timezone to /etc/localtime cause this *changes* the time value! but we need only a different interpretation)
b) date shows correct time when 1.b is given (hwlock UTC vs. date with UTC). When a user would change UTC to his local timezone then also the system time value (not the hwclock) must be changed. Here this is could be done ex. with tzselect tool or copying timezone file to /etc/localtime, but better do this in a own step.
c) date shows false time when 1.c is given (all clocks wrong). For this (and as a fallback) we should have a step where a user should be able to set the timezone and value by hand/dialog, with this values we modify system time(date) and BIOS clock(hwclock).

So what's our steps for timesetting?
Ideally we never would have any problem when users would set HWCLOCK and TIMEZONE in bootloader as boot parameters ;-)
But if a user boot boot the cd without these in Peking, Chicago or Brussel we must ask him some questions:
a) Is your hardware clock set to localtime or UTC?
b) Based on this answer whe should present the output of date or date -u
c) Ask him: Is this the correct time displayed also on your watch? (timezone is nor relevant this step!)
Based on his answer time value must probably set by hand/dialog and corrected with date -s "value".
d) Next question is: Where do you live, what's your timezone?
Based on the answer we should set/export TZ and display the time again with date
e) Assumed that last step shows the correct local time for the user (datetime value AND timezone) we should ask: Do you want keep your hardwareclock(BIOS) in localtime or UTC?

What we have this moment? A correct system time based on users selections. We have also TIMEZONE var and HARDWARECLOCK for the generated rc.conf later. As a last step we now should set the hwclock/BIOS according to the system time (either as localtime or UTC, based on HARDWARECLOCK).
During system config we must also copy the according timezone file to /mnt/etc/localtime early (before any chroot'ing), but we should NOT do this in the live cd system!

IMHO this could be the way we should handle time setting things during installer/aif.

Great post Gerhard, but we should really discuss this more in public, so I quoted you and added my thoughts on the arch-releng ML.
See http://www.archlinux.org/pipermail/arch-releng/2009-February/000415.html

The date time stuff is being refactored. See  FS#13196 

We don't even use tzselect anymore now.