> Hi all.
>
> >> IMHO, a simple command parameter giving the offset in hours
> >> (half-hours?) from UTC to the kernel is fine...
>
> > At most half-hours (Adelaide, South Australia has a half-hour
> > timezone).
>
> My understanding is that there's two or three countries in Asia with
> timezones on quarter hour boundaries as well, so at least that level
> of granularity would be needed.
Well, we could go down to a one minute resolution or more, that's not
really a problem. But what about daylight savings, is it univesally on
the same day and by exactly one hour everywhere? I'm sure there are even
more gory details like leap-seconds and such. The zoneinfo database
handles all the special cases nicely and is very flexible. I don't think
we want to duplicate all that inside the kernel.
As another note, I have looked more into the fsck vs. hwclock who's-first
debate. There is a problem with running hwclock before /usr/lib/zoneinfo
is mounted (not just before fsck'ing root). Hwclock expects the timezone
database to be available when it runs (it uses the C-library mktime()
which reads zoneinfo), so running it very early won't work by default.
The solution is simple enough and can still be handled in userspace. Copy
the relevant entry from the terminfo database to /etc/localtime, and set
the TZ environment variable to point to it, or give all the timezone
details in the variable itself (man tzset). Then call hwclock very early
from your boot scripts (/ still mounted ro, and un-fscked).
I have looked at the code from both hwclock and glibc2.1 and it seems
either aproach above should work painlessly, although I have tested
neither (I run my RTC in UTC ;) Again, Redhat nor Debian do this, but it
would IMHO be the right thing(tm).
Cheers,
-Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/