lkml.org 
[lkml]   [1999]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [from the cache]
©2003-2011 Jasper Spaans