>> I think you were assuming that the routines to determine the DST
>> dates would need to be in the kernel as well, and I'd agree that
>> suchlike routines would be far too much kernel bloat, but
>> they're not needed for the purposes stated, as the above will
>> achieve the same purpose.
> I would be worried about situations where these values are
> specified in LILO for unattended boot. Systems don't change
> their time zone very often, so RTCTZ would be OK, but one of
> Linux's strength is that you can put it in a lights-out
> environment. When it reboots, it has to have the correct time.
I have to agree here, as I've set up several suchlike systems, and
it's for precicely that reason that I'm only discussing the issues
here rather than working on a patch - this is something where the
design HAS to be right before any coding starts.
> I don't know how many RTC chips provide a "DST in use" flag.
I can't speak for other architectures, but the common RTC chip on the
ix86 architecture is the 148???? (I forget the rest of the number),
and this has two flags of interest. The first is writable, and tells
the chip whether or not to implement DST, and the second is read only
and states whether the chip is currently returning DST or non-DST
time. I don't have the technical docs handy, so I'll refer to these
two flags as DSTenable and DSTinuse respectively in the text that
follows.
As far as I can see it, the basic kernel algorithm would be something
like the following pseudocode:
1. Define two kernel parameters, configurable at compile time, as
follows:
__s16 rtctz = Non-DST timezone offset from UTC in minutes
__s8 rtcdst = RTC's DST shift in minutes
Note that the latter will normally be +60 and can be regarded as
being architecture specific.
2. Read the RTC registers, producing:
time_t sysclock = RTC time in time_t format
boolean dstused = DSTenable && DSTinuse
3. Perform the following calculations:
sysclock -= 60 * RTCTZ
if (dstused) {
sysclock -= 60 * RTCDST
}
Once that's been done, the kernel's system clock will reflect the UTC
time indicated by the RTC if RTCTZ is set correctly, and since there's
nothing in there that changes any register in the RTC, there's nothing
that can affect the value the RTC returns.
> It would be a shame for the time to be fixed up correctly by
> user space code when DST kicks in, only to be messed up by an
> hour a week later when the power fails.
That's why I would only see this code referencing the flag in the RTC
chip, and not tweaking it itself, as stated above.
> Maybe it's possible for the user-space code to be made aware of
> the possibility of these flags having possibly messed up, but
> you'd have to avoid situations such as some versions of Windows
> have, where people working late on DST changeover night
> (especially those booting multiple Windows versions) find their
> clock changed multiple times.
That's primarily because Windows actually tweaks the RTC chip itself,
and as I see it, that's one thing we MUST avoid doing.
Incidentally, one thing that's often overlooked is that we do NOT need
to ensure that the shift in to and out of DST in the RTC occurs on the
correct date. All we need is to know whether the time returned by the
said chip is the DST or non-DST time, and what the DST shift used by
that chip is, which is why the above pseudocode works.
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/