From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BUD1I-00012t-0c for qemu-devel@nongnu.org; Sat, 29 May 2004 19:13:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BUD1G-00012F-6T for qemu-devel@nongnu.org; Sat, 29 May 2004 19:13:39 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUD1G-00012C-4t for qemu-devel@nongnu.org; Sat, 29 May 2004 19:13:38 -0400 Received: from [206.72.67.39] (helo=claudius.sentinelchicken.org) by monty-python.gnu.org with smtp (Exim 4.34) id 1BUD17-0004Cs-PY for qemu-devel@nongnu.org; Sat, 29 May 2004 19:13:30 -0400 Date: Sat, 29 May 2004 16:13:27 -0700 From: Tim Subject: Re: [Qemu-devel] Changing RTC from UTC to local time Message-ID: <20040529231327.GC1690@sentinelchicken.org> References: <40B8A0B1.3040601@fabianowski.de> <200405291023.18228.kyle@silverbeach.net> <40B8DB75.5050005@fabianowski.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40B8DB75.5050005@fabianowski.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > You can set a PC's RTC to UTC or any other time zone for that matter if > you want to. However, according to the original design (dating back to > the olden days of the first IBM PC), the RTC should be running in local > time. Probably makes sense to make this the default. > I guess one could make this a runtime option. But that would only > clutter the command line, as there would be one more parameter just to > set the RTC's time zone. A compile time option makes much more sense > IMHO. However, this would only benefit very few people as most people > download binaries. > > Keeping in mind that Linux and *BSD both can deal with a standard PC RTC > running in local time, are you sure that QEMU really needs the option of > having the RTC run in UTC? It is difficult to anticipate future uses of any piece of software. I can think of a few cases where I would want to set this behavior on a case-by-case basis, for example, running an OS that was installed on real hardware originally. Therefore, if it were to come down to a vote, I would say it should be a command line option. The patch submitted earlier illustrates how trivial it would be to make it configurable at runtime. As for a cluttered command line.. yes, I agree it is getting cluttered. In addition, the current syntax will eventually limit future emmulated hardware (scsi bus, more than 4 IDE disks, etc). Is there any effort currently in the works to move the command line options into a config file for more versatile runtime configuration? When I find time, I might work on this, if no one else has started it... tim