On Mon, Oct 29, 2007 at 01:19:51AM +0000, Miguel Lopes Santos Ramos wrote: > > From: Holger Kipp <[EMAIL PROTECTED]> > > 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) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
