Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

3 messages, 3 authors, 2002-03-28 · open the first message on its own page

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

From: Ethan Benson <hidden>
Date: 2002-03-28 13:04:42

On Thu, Mar 28, 2002 at 12:28:27PM +0100, Michel Lanners wrote:
In arch/ppc/kernel/time.c, kernel time is set from the RTC, implicitly
taking RTC for GMT time. Under MacOS, however, it's localtime. On pmac,
we use the GMT offset MacOS stores in nvram to correct this, and correct
kernel time to real GMT. We also set kernel timezone info, but it's use
is discouraged (have a look at man settimeofday).
this is broken.  the kernel should just use the time stored in nvram
and ignore the crap macos is keeping there regarding time zones.

the solution to the `windows controls the hardware clock' problem was
made many years ago, hwclock can be told whether the RTC is in
localtime or GMT, just about every distro asks you this on install (at
least on x86 debian does on powerpc too).

we should just deal with the RTC exactly how its delt with on x86, if
you have windows (or in our case MacOS) you tell hwclock the RTC is in
localtime and let it deal with it, if you don't have MacOS/windows you
tell it you have the RTC in GMT like its supposed to be and all is well.
Now, when this offset is wrong (like when DST switched and you didn't
boot MacOS since), your intial kernel time will be wrong. However, the
which demonstrates exactly why this crap in the kernel trying to be
like macos is just plain wrong and broken.
The question, of course, is whether Linux should maintain this GMT
offset in nvram, since it uses it's information. If so, then who should
maintain it where?
no it should not.  the kernel should NOT know or care what the
timezone is, that belongs in userspace not kernel space.  period.

the feilds macos sets should be ignored entirely by linux, not read,
not written.
My proposition would be to correct this everytime that the RTC is
updated (since the GMT offset belongs logicaly to the RTC function
block). Debian does this on every system shutdown.
please don't forget systems that don't have legacy MacOS, these
systems will keep the RTC in GMT like its supposed to be.
Obviously, the easiest thing to do is do nothing and entirely rely on
the bootup scripts to set the correct time.
this is of course the correct solution, this problem was met and
solved YEARS ago on x86 its stupid that powerpc is fooling around with
it when there is already a well established and working solution.
Comments anyone?
see above, in short this `lets pretend we are MacOS!!' crap in the
kernel should be *REMOVED* the kernel should not know or care about
timezones or DST, it should just read the RTC and ignore these macos
fields.  the standard bootup scripts running hwclock will pass --utc
or --localtime depending on how the user configured it and all will be
fine, just like on x86 for dealing with windows.

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2002-03-28 16:19:56

On Thu, 28 Mar 2002, Ethan Benson wrote:
On Thu, Mar 28, 2002 at 12:28:27PM +0100, Michel Lanners wrote:
quoted
In arch/ppc/kernel/time.c, kernel time is set from the RTC, implicitly
taking RTC for GMT time. Under MacOS, however, it's localtime. On pmac,
we use the GMT offset MacOS stores in nvram to correct this, and correct
kernel time to real GMT. We also set kernel timezone info, but it's use
is discouraged (have a look at man settimeofday).
this is broken.  the kernel should just use the time stored in nvram
and ignore the crap macos is keeping there regarding time zones.

the solution to the `windows controls the hardware clock' problem was
made many years ago, hwclock can be told whether the RTC is in
localtime or GMT, just about every distro asks you this on install (at
least on x86 debian does on powerpc too).

we should just deal with the RTC exactly how its delt with on x86, if
you have windows (or in our case MacOS) you tell hwclock the RTC is in
localtime and let it deal with it, if you don't have MacOS/windows you
tell it you have the RTC in GMT like its supposed to be and all is well.
Perhaps someone can writes a utility to `patch' MacOS to treat the hardware
clock being in GMT/UTC/Zulu time? I did a similar thing for AmigaOS many many
years ago.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

From: benh@kernel.crashing.org
Date: 2002-03-28 17:18:59

we should just deal with the RTC exactly how its delt with on x86, if
you have windows (or in our case MacOS) you tell hwclock the RTC is in
localtime and let it deal with it, if you don't have MacOS/windows you
tell it you have the RTC in GMT like its supposed to be and all is well.
Which means that during boot, the kernel will have a wrong (local) time
instead of UTC. That can be annoying.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help