Hi all, Some people have reported issues with the way we do time/date/timezone stuff. most of them are already fixed but we still have 2 open. (http://bugs.archlinux.org/task/12933, http://bugs.archlinux.org/task/13196) One of the issues is cosmetical, the other functional. I would like to implement this correctly so now is a very good time to all think about how time _should_ be handled, and since I'm not an expert in this, I need your advice. A good starting point would be Gerhard's excellent comment from http://bugs.archlinux.org/task/12933#comment40281 I'll quote it here and add my thoughts below. =========== QUOTE Gerhard ================= +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. ========== END QUOTE ========
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!
Why before any chrooting? what do you mean with "we should NOT do this in the live cd system!" ? I mean, the installer runs in the liveCD, so from the livecd we have to copy /etc/localtime to /mnt/etc/localtime, no? Some thoughts: 2a) If a user would happen to live in the UK (GMT timezone, eg UTC+0) then for him UTC === localtime right? so by "coincidence" he would have the correct time. Is there any functional difference between a hardware clock running "as UTC" or a hardware clock running "in localtime for the UTC/GMT timezone" ? I think not but I'm not sure. Similarly 2b) On the installCD we use UTC by default, so this means the time will _only_ be correct if the users clock is in UTC _and_ he lives in a UTC/GMT timezone, no? I think it would be really interesting to compare your ideas to what tpowa has written: http://projects.archlinux.org/?p=archboot.git;a=blob;f=usr/share/archboot/tz... About Gerhard's solution: if the clock is UTC, shouldn't we first ask for the timezone and then ask for the date? because the time we will present in 2b) is probably incorrect if we don't know the timezone yet. Shouldn't we do a->d->b->c->e ? About tpowa's stuff: what's line 47-49 for? in dohwclock, why don't you add --noadjtime ? Note that I have sort of ported tpowa's tz script into aif ( see http://github.com/Dieterbe/aif/commit/5cd407fbb9b44b476ae7c9d460594322f465c2... ) but of course it will probably need to change depending on this discussion. Dieter