Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers
Tasklist

FS#12933 - tzselect in set_clock() ignores "local time" option

Attached to Project: Release Engineering
Opened by Evangelos Foutras (foutrelis) - Saturday, 24 January 2009, 17:18 GMT
Last edited by Dieter Plaetinck (Dieter_be) - Monday, 30 March 2009, 20:02 GMT
Task Type Bug Report
Category ArchISO
Status Closed
Assigned To Aaron Griffin (phrakture)
Gerhard Brauer (GerBra)
Dieter Plaetinck (Dieter_be)
Architecture All
Severity Low
Priority Normal
Reported Version 2009.01-beta
Due in Version 2009.08-alpha
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Even though HARDWARECLOCK is set to "local", tzselect assumes current time is in UTC.

I've attached a screen capture from archlinux-2009.01-ftp-x86_64.iso (alhpa) running in vmware. When asked, I answered that the hardware clock is in local time. However, when I'm asked to confirm the time values presented to me, both local and universal time should be minus 2 hours.

Were I to select "Yes", it would probably set the correct timezone/time, but it's quite confusing when you are prompted to confirm wrong values.
This task depends upon

Closed by  Dieter Plaetinck (Dieter_be)
Monday, 30 March 2009, 20:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  got rid of tzselect. see  FS#13196  for all date/time refactoring
Comment by Greg (dolby) - Saturday, 24 January 2009, 20:28 GMT
What was the time when you booted into the system? Was it correct?
Comment by Evangelos Foutras (foutrelis) - Saturday, 24 January 2009, 20:55 GMT
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. :)
Comment by Greg (dolby) - Saturday, 24 January 2009, 21:13 GMT
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.
Comment by Evangelos Foutras (foutrelis) - Saturday, 24 January 2009, 22:10 GMT
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.
Comment by Evangelos Foutras (foutrelis) - Sunday, 25 January 2009, 02:05 GMT
Btw, the grub issue was probably caused by  FS#12917 . Installation worked flawlessly after using a local copy of x86_64 [core].
Comment by Evangelos Foutras (foutrelis) - Sunday, 25 January 2009, 02:09 GMT
@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?
Comment by Dieter Plaetinck (Dieter_be) - Monday, 26 January 2009, 20:15 GMT
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.
Comment by Michael Laß (Bevan) - Saturday, 31 January 2009, 21:47 GMT
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.
Comment by RicardoH (richer) - Monday, 02 February 2009, 05:50 GMT
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
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 22 February 2009, 20:57 GMT
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.
Comment by Gerhard Brauer (GerBra) - Thursday, 26 February 2009, 13:10 GMT
+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.
Comment by Dieter Plaetinck (Dieter_be) - Thursday, 26 February 2009, 20:02 GMT
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
Comment by Dieter Plaetinck (Dieter_be) - Monday, 30 March 2009, 20:01 GMT
The date time stuff is being refactored. See  FS#13196 

We don't even use tzselect anymore now.

Loading...