NetBSD Problem Report #9373
Received: (qmail 4503 invoked from network); 8 Feb 2000 09:48:48 -0000
Date: Tue, 8 Feb 2000 01:48:44 -0800 (PST)
From: "Erik E. Fair" <email@example.com>
Subject: kernel should convert RTC value to UTC without RTC_OFFSET option
>Synopsis: kernel should convert RTC value to UTC without RTC_OFFSET option
>Arrival-Date: Tue Feb 08 01:50:59 +0000 2000
>Last-Modified: Sun May 22 15:22:54 +0000 2016
>Originator: Erik E. Fair
International Organization of Internet Clock Watchers
System: NetBSD digital.clock.org 1.4.2_ALPHA NetBSD 1.4.2_ALPHA (DIGITAL) #10: Mon Jan 10 22:38:56 PST 2000 firstname.lastname@example.org:/usr/obj/sys/arch/alpha/compile/DIGITAL alpha
The MacOS keeps its hardware Real Time Clock (RTC) in local time.
NetBSD has an option(4) to deal with this: RTC_OFFSET
However, this is a compile-time option, and this is not
flexible enough (NetBSD users do not all live in the same
timezone - so we have to have 24 binary kernel distributions?
Also there are laptoys which change timezone as the user travels).
While it is possible to simply set the RTC to UTC/GMT, this
is inconvenient, if you alternately boot NetBSD and MacOS.
Fortunately, the Macintosh also keeps its location
(latitude/logitude, no less!) and offset from UTC in
"extended parameter RAM" (non-volatile). This means that
a suitably modified "clock" driver can read the clock, and
the P-RAM offset, and correctly set NetBSD's system time
at boot, without hosing up the the RTC value from MacOS's
point of view. The URL
documents that these values are available. A little more
searching in the Apple documentation should reveal the
format of "extended parameter RAM" and make this change
In addition, it may be desireable to add something to rc.local
for macppc to change the link for /etc/localtime to whatever is
read from Macintosh P-RAM.
This PR also applies to port-mac68k
From: "Perry E. Metzger" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Subject: Re: port-macppc/9373 kernel should convert RTC value to UTC without RTC_OFFSET option
Date: 03 Apr 2003 11:56:02 -0500
Has this been obsoleted by MacOS X? If so, may I close the PR?
Perry E. Metzger firstname.lastname@example.org
State-Changed-When: Thu Apr 3 09:02:57 PST 2003
Waiting for information from Erik...
State-Changed-When: Thu Apr 3 11:06:31 PST 2003
Erik said it does still need to be done.
Responsible-Changed-When: Thu Apr 3 11:06:31 PST 2003
Erik said he has the ability to do this.
From: "Erik E. Fair" <email@example.com>
To: "Perry E. Metzger" <firstname.lastname@example.org>
Subject: Re: port-macppc/9373 kernel should convert RTC value to UTC
without RTC_OFFSET option
Date: Thu, 3 Apr 2003 11:52:07 -0800
Not so far as I know - I seriously doubt that MacOS X keeps the
TOY/RTC (the hardware battery backed clock) in UTC; that would make
dual booting with MacOS 9 (which they explicity support) have bad
The MacOS has depended on two things: hardware keeps "local" time,
and the Parameter RAM (PRAM) has the offset from UTC (also corrected
for daylight savings time), so MacOS 9 can keep its kernel time
ticking in local time as always, and MacOS X can keep kernel internal
time as UTC by applying the UTC offset from PRAM to the time read
from the battery-backed hardware clock at boot time.
NetBSD needs to do what MacOS X clearly does. We therefore need to
know where the UTC offset is kept in PRAM, and how to read it (what
format it is). Our RTC_OFFSET kernel option is, alas, compile-time
only and too static for use with a travelling laptoy.
We will also need a utility to set the UTC offset in the Mac's PRAM,
so that when the hypothetical laptoy moves, the value can be adjusted
as required without booting the MacOS (either 9 or X). Might be a
good idea to change the localtime symlink in /etc at the same time.
Responsible-Changed-When: Sun, 22 May 2016 15:22:54 +0000
I don't know how to fix this - I merely reported it.
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.