Date: Mon, 29 Oct 2007 05:29:29 -0500 From: Mike Pritchard <mpp@mail.mppsystems.com> To: Miguel Lopes Santos Ramos <miguel@anjos.strangled.net> Cc: hk@alogis.com, freebsd-stable@FreeBSD.org, stable@FreeBSD.org, eugen@kuzbass.ru Subject: Re: date manupulation strangeness Message-ID: <20071029102929.GA25240@mail.mppsystems.com> In-Reply-To: <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net> References: <20071028211538.GA92424@intserv.int1.b.intern> <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 29, 2007 at 01:19:51AM +0000, Miguel Lopes Santos Ramos wrote: > > From: Holger Kipp <hk@alogis.com> > > 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071029102929.GA25240>