From owner-freebsd-stable@FreeBSD.ORG Mon Oct 29 21:35:26 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EBA116A417 for ; Mon, 29 Oct 2007 21:35:26 +0000 (UTC) (envelope-from mpp@mppsystems.com) Received: from lugdush.gulftel.com (lugdush.gulftel.com [216.231.163.39]) by mx1.freebsd.org (Postfix) with ESMTP id B0FE413C4A8 for ; Mon, 29 Oct 2007 21:35:25 +0000 (UTC) (envelope-from mpp@mppsystems.com) Received: from localhost (localhost [127.0.0.1]) by lugdush.gulftel.com (Postfix) with ESMTP id 9B4E8C391; Mon, 29 Oct 2007 05:29:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at gulftel.com Received: from lugdush.gulftel.com ([127.0.0.1]) by localhost (lugdush.gulftel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN8nPL9PNdO2; Mon, 29 Oct 2007 05:29:33 -0500 (CDT) Received: from mail.mppsystems.com (unknown [10.17.28.253]) by lugdush.gulftel.com (Postfix) with ESMTP id 73C23C352; Mon, 29 Oct 2007 05:29:29 -0500 (CDT) Received: by mail.mppsystems.com (Postfix, from userid 1000) id 2904C17025; Mon, 29 Oct 2007 05:29:29 -0500 (CDT) Date: Mon, 29 Oct 2007 05:29:29 -0500 From: Mike Pritchard To: Miguel Lopes Santos Ramos Message-ID: <20071029102929.GA25240@mail.mppsystems.com> References: <20071028211538.GA92424@intserv.int1.b.intern> <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: hk@alogis.com, freebsd-stable@FreeBSD.org, stable@FreeBSD.org, eugen@kuzbass.ru Subject: Re: date manupulation strangeness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2007 21:35:26 -0000 On Mon, Oct 29, 2007 at 01:19:51AM +0000, Miguel Lopes Santos Ramos wrote: > > From: Holger Kipp > > On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: > > > On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: > > Sat Oct 27 18:59:59 UTC 2007 > > This is a lot of fun! Bugs like this go unnoticed for years... > It is also very exciting finding people at GMT+8. Mind you, we programmers who live at > GMT+0 do a lot of timezone errors because we look at a time and often don't know > whether it's localtime or gmt. At least I do. Then we only find out when we > change to summer time. > > The problem is of course in src/bin/date.c, line 268. Someone added the > following on revision 1.32.2.4: > 267: /* Let mktime() decide whether summer time is in effect. */ > 268: lt->tm_isdst = -1; > > Now, who's mktime() to know? > This line is erasing the output of strptime(), and strptime() knows better than > anyone what the user might have wanted! > > See my test source code bellow. date first fills up a tm structure using > localtime(time(0)) so that the data which the user does not supply is extracted > from the current time. Then, it calls strptime to parse the user time using > these defaults. It's summarized in function test1() of my test code. > > Historically, the behaviour was just this (actually, like test2()). The person > who added line 268, wanted to solve the problem of setting a date across DST, > but the way he/she did it is not, in my opinion, the best. > As we have discouvered, it does not work when the user supplies good DST data, > because the line tm_isdst = -1 erases it. > Now, what should perhaps be erased is the default dst data. So the line tm_isdst > = -1 should be moved up to line 191, between localtime() and strptime(). > > The code would behave like my test3() function. > See the test output (using LC_ALL=C and TZ=Asia/Krasnoyarsk): [lots of stuff trimmed from the above] DST/CST time changes when setting the time backwards has been at your own risk for a long time. Back in 1995/6 when I fixed a lot of utilities to enforce the password expiration date/time, I found it was off by +/- 1 hour if I was setting dates and times that would cross DST changes. Not a big deal then, but I think I got them all to work correctly. But if I recall correctly, if you wanted to really test those type of changes by setting the system date/time back, it was better to set the date/time to a period well before the DST change, verify the system understood it was in the proper time zone (probably a reboot), THEN move the clock up to just before the DST time change and let it roll over. -- Mike Pritchard mpp @ FreeBSD.org "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison (1787)