Messages in this thread | | | Date | Fri, 21 May 1999 20:16:37 +0100 (GMT) | From | Riley Williams <> | Subject | Re: i386/RTC: old problem, new solution? |
| |
Hi Richard.
>>> maybe the problem running RTC in non-UTC time is known to you, >>> including its implications. Basically the kernel lacks two >>> things when booting:
>>> 1) time zone >>> 2) Whether RTC runs UTC or local time
===8<=== CUT ===>8===
> In fact, there already is a patch in the kernel: > CONFIG_APM_RTC_IS_GMT, but it's a temporary hack, until a better > scheme is implemented. The reason is that the kernel needs to > know the timezone the RTC is stored in when restoring the system > clock after a suspend/resume cycle. Automatically computing the > difference has its problems.
I have to admit that I wasn't aware of that patch, and by the sounds of it, it could do with being extended to cover the boot scenario where the kernel currently has to wait until `hwclock --hctosys` or `hwclock --utc --hctosys` is run to discover what timezone to use.
Let's have a look at the cases that would need to be dealt with:
A. RTC is set to UTC.
B. RTC is set to the local time for a region that does not implement Daylight Saving Time.
C. RTC is set to the local time for a region that implements Daylight Saving Time, and does not have a flag to indicate whether it is running in Summer or Winter mode, or the flag is not reliably set.
D. RTC is set to the local time for a region that implements Daylight Saving Time, has a flag to indicate whether it is running in Summer or Winter, and that flag is reliably set.
Note that case (A) is actually the subset of case (B) where the time difference between local time and UTC happens to be +0000 and can be treated as such, so only cases (B), (C) and (D) actually need to be considered.
Next, what considerations do those cases throw up? I can see the following:
1. As far as I'm aware, all timezones are specified as being an exact number of minutes different from UTC, in the range from -12 hours 15 minutes to +12 hours 15 minutes. This equates to a difference of between -735 and +735 minutes from UTC, so can safely be stored in a __s16 on all architectures.
2. We need to know the time difference between UTC and local time, and as stated above, this can have a value in the range -735 to +735 minutes. This should be a kernel parameter that can be set on the kernel command line, my recommendation being "rtctz".
Its default value should be one of two, probably depending on a kernel compile time option, as follows:
a. RTC is assumed to store UTC time, default +0000.
b. RTC is assumed to store local time, default is therefore the current timezone difference on the compiling system.
Note that option (b) can be used to set ANY timezone simply by doing similar to the following...
TZ=MST make bzImage
...which has the effect of making that make run as if the local timezone was MST even if it wouldn't otherwise be the case.
3. For case (D), and especially for case (C), we need to know the dates on which the RTC gets shifted in to and out of DST. There are at least three variants that I'm aware of, and probably several others as well. The ones I've met are as follows:
a. The UK runs DST from the last Sunday in March to the last Sunday in September.
b. The USA runs DST from the first Sunday in April to the last Sunday in September.
c. In the southern hemisphere, the seasons are shifted by six months, so they have DST from September/October to March/April, the opposite half of the year to what the northern hemisphere uses.
Now, how do we deal with these? Here's my suggestion:
1. Case (A) is actually the subset of case (B) where the time difference between local time and UTC is +0000.
2. Define a kernel parameter "rtctz" which stores the result of the calculation (localtime-UTC) in minutes, and has as its default value the relevant value on the system where the kernel is compiled.
3. If we find case (D) to apply, use the RTC's "DST is active" flag to decide whether to apply an extra hour of timezone difference.
4. Case (C) is the problem case, and I can see no easy way of dealing with it. Suggestions are most certainly welcome.
Comments?
Best wishes from Riley.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
- 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/
| |