On Tue, 25 May 1999, Riley Williams wrote:
> 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.
>
> If my reading of the situation is correct, then those details are all
> irrelevant anyway. All the kernel cares about is the state of the RTC
> on the system, and few (if any) RTC chips go into that sort of detail.
> Looking at it from that point of view, just TWO kernel variables will
> deal with all cases of interest. Have a look at the specs for the
> various RTC chips in use, and you'll generally find that they deal
> with dates and times as follows:
Ok, now I get what your aiming at: Support just the hardware view of
time.
[snipped details on RTC chips and patch]
In that case, the whole thing reduces to applying a pre-computed offset to
whatever is read from the RTC. Since we are going to read the RTC anyways
on boot, then we could add such an offset if you want... but only at that
point (ie. in time.c:time_init()). I don't think it is a good idea to
fake the RTC time to userspace programs as it would probably confuse them.
At first glance that is what your patch appears to be doing, right?
Also, your rtctz script is a nifty way of extracting the timezone
information when compiling, but I think I would be better if it was a boot
parameter, say tzoffset=3600 where the offset is in seconds (so math is
easy.) Else, how do you distribute kernel binaries to different parts of
the world? ;-)
Lastly, the problem we are trying to solve seems to be mostly a non-issue,
at least at boot, since hwclock can set the system clock properly before
anything important happens. The more interesting problem is the one
Richard brought up with APM. I think it goes like this:
1) DST changeover is about to happen
2) the machine goes into APM, before doing so the kernel in apm.c
computes a timezone offset to be used when coming out of APM.
3) timezone changeover occurs due to DST going on or off.
4) machine comes out of APM, read CMOS and applies wrong offset, sytem
time is now warped.
IMHO, the obvious solution would be to monitor the DST flag (if present)
and if it changed during APM adjust the offset accordingly. Someone who
knows where the DST flag is on the RTC should implement this ;-)
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/