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    [W:0.026 / U:60.624 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site