Please remember this is bug is being dealt with with util-linux perspective
when reading my answers...

On Sun, 01 Jan 2006, Nate Eldredge wrote:
> Right.  Which is kind of painful in the daylight savings case.  I can't 

Correct. It is *flat out impossible* to fix this issue completely (as in do
everything transparently) in util-linux.

Either one must have one's clock on UTC as any non-braindamaged system does,
OR one's /etc/localtime better be in the root partition.  Otherwise, one has
to keep daylight savings in mind and fix TZ by himself... or risk breakage.

> Yes.  Note that setting TZ is rather inconvenient.  First because you have 

Using a hardware clock not in UTC is extremely inconvenient, as well. In
fact, supporting that has been extremely inconvenient for long YEARS, now.
I'd have dropped that support a loooong time ago.

At least this time, I know there is nothing better we can do.  The user has
two choices, either he must have the hw clock in UTC, or he must have his
system fully timezone-capable since instant zero, which means /etc/localtime
MUST be in the root partition.

Setting TZ is kind of a middleground fix, a best effort fix if you will.
And it does work, but it means people have to go and manually fix TZ when
entering and leaving daylight savings time...

> forget which package has the config script where you select your timezone, 

libc6 has tzconfig.

> but I guess it could in principle apply it in both places.  But that's 

Yes, it could be changed.

> kind of ugly, and anyway the Debian philospohy is not to force people into 
> using config scripts.

Well, if we were to do it in the strict Debian way (always do what is more
correct technically speaking), we would drop non-UTC support. It complicates
the boot procedure, it is prone to *very* subtle bugs, and it is technically
insane to have a hardware clock in local time, and Microsoft itself only
does so because they were dumb enough not to fix that in Windows 95, and
because of MSDOS before that.

But we try our best to support it, since people seem to find it useful.  If
that means they will have to jump through loops, that means they will have
to jump through loops.

But we certainly need to document this better, and d-i should warn the user
right away that using the hardware clock in local time mode IS NOT a good
idea, and that the system might not be able to deal automatically with
daylight savings in that case.

> >What would happen in the typical broken configuration?
> >
> >Non-UTC, /usr separate, no TZ defined anywhere:
> > 0. kernel boots with wrong time (even if it reads the RTC by itself)
> >* 1. hwclock sets the kernel UTC time to the local time in the RTC,
> >    and thus the system clock could be wrong by several hours in either
> >    direction.
> > 2. System runs with wrong time. e2fsck can croak, etc.
> > 3. something mounts /usr
> >* 4. hwclock runs, and tells the user a completely ludricous time
> >    (timezone applied twice :P) <=== We could fix the mess here, so
> >    if the user doesn't hit a bug (e.g. e2fsck) before, he would not
> >    suffer much from his broken config.
> >    hwclock MUST be run after /usr is mounted to be able to help fix
> >    the mess (well work around it, realy).
> 
> I don't have my unstable box handy to check right now, but it gets fixed 
> eventually.  I think when hwclock runs after /usr is mounted, it sets the 
> time correctly.  So it's only wrong before that point.  I used to have 

Yes, but this bug showed up exactly because it is not running after /usr
anymore (which is in fact broken behaviour and should be fixed, as I
explained).

> You know, another solution would be to relocate the whole 
> /usr/share/zoneinfo hierarchy to the root filesystem.  I don't really like 

That's 5MiB more in the root filesystem.  One can always ask the glibc
maintainers to do it, or one can ask them to add something that keeps track
of /etc/localtime and updates it every time glibc is updated or tzconfig is
run, so only the required data would end up in the root partition (and
/etc/localtime would not be a symlink anymore).

I won't though. If the submitter feels like doing it, be my guest. Remember
to point the glibc people to this bug so that they get the whole story.

> to local time, which isn't really the Unix way.  (I only did it because I 
> was dual-booting Windows, which insisted on having the hw clock in local 
> time.)

Does it even do that anymore?  Anyway, just lie about your timezone to
Windows so that you get the correct time, and keep the clock in UTC.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh