From owner-freebsd-bugs Mon Apr 10 09:56:15 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA10120 for bugs-outgoing; Mon, 10 Apr 1995 09:56:15 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA10108 for ; Mon, 10 Apr 1995 09:56:12 -0700 Received: by halloran-eldar.lcs.mit.edu; id AA03250; Mon, 10 Apr 1995 12:56:02 -0400 Date: Mon, 10 Apr 1995 12:56:02 -0400 From: Garrett Wollman Message-Id: <9504101656.AA03250@halloran-eldar.lcs.mit.edu> To: uhclem%nemesis@fw.ast.com Cc: freebsd-bugs@freefall.cdrom.com Subject: bin/327: Clock management punishes you if CMOS != GMT FDIV020 In-Reply-To: <199504092021.NAA01474@freefall.cdrom.com> References: <199504092021.NAA01474@freefall.cdrom.com> Sender: bugs-owner@FreeBSD.org Precedence: bulk <> Number: 327 > If you elect to keep the CMOS at local time, the installation will offer > you cities (not many choices in CST by the way), then show you a time with > the CST suffix, WITH THE GMT OFFSET ADDED even if you don't want it. The first thing it asks you is: Is $4, $1 $2 $3 $6 the correct current date and time? (with appropriate values for the positional variables). If your CMOS clock is set to local time, then this will be the current time, and so you are supposed to answer `y'. It then tells you: Unless your local time is GMT, this probably means that your CMOS clock is on local time. In this case, the local times that you will be shown will be incorrect. You should either set your CMOS clock to GMT, or select option 98 from the main menu after selecting a timezone. Can't get much more explicit than that. Note that we VERY EXPLICITLY do not allow users to select something like `CST' as their timezone, because the notion is not well-defined. Instead, we ask: Please select a location from the following list which has the same legal time as your location: This is a very different question, because the time zone database keeps track of summer time arrangements and changes in zone boundaries. Thus, for most of the U.S. locations that observe ``Central time'', `Chicago' is the correct choice, because most locations in that area started observing both standard and summer time at the same time as Chicago did. Most parts of Indiana started out with Eastern, summer time, but in 1946, Indiana decided not to observe summer time, and so those locations use `Fort_Wayne'. Starke County, Indiana, used to be on Central time following the `Chicago' definition, but in October 1991 it decided to follow the rest of Indiana and be on Eastern time all the time, with no summer time; hence, `Knox_IN'. Michigan has always been in the Eastern zone, but didn't observe summer time from 1968 to 1973, hence `Detroit'. At some point in time, I'll re-do all this a la `dmenu'. (Or Jordan is welcome to...) It's all explained in gory detail in /usr/src/share/zoneinfo. > It then asks "Is this what you wanted?". The normal user isn't going to > realize that all the installation process is asking about at that point is > the CST suffix and will answer the question NO because the time is wrong. I agree that there is a problem here, but there's nothing we can do about it, since we can't correct the time without knowing what the user's timezone is. I probably should have asked ``Is this the time zone you wanted?'' > Also note that if you have CMOS set to LOCAL, and boot the system in maint > mode, the date shown is wrong (behind by several hours). Another good reason to use a UTC CMOS clock... There's no other way it can work the way you want it. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant