[arch-releng] Dates, times, timezones.

[Dieter Plaetinck]

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/tz;h=d7446ec04ad45812a5b939ea2d82cb86e55df66b;hb=c9266cc5f655c8dbe96b6063a026eadcbb4f0aec

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/5cd407fbb9b44b476ae7c9d460594322f465c24f )
but of course it will probably need to change depending on this
discussion.


Dieter