Date: Wed, 31 Oct 2007 21:00:55 GMT From: Miguel Lopes Santos Ramos <miguel@anjos.strangled.net> To: mpp@mppsystems.com Cc: hk@alogis.com, freebsd-stable@FreeBSD.org, stable@FreeBSD.org, eugen@kuzbass.ru Subject: Re: date manupulation strangeness Message-ID: <200710312100.l9VL0tit006227@satan.anjos.strangled.net> In-Reply-To: <20071029102929.GA25240@mail.mppsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Mike Pritchard <mpp@mail.mppsystems.com> > [...] > DST/CST time changes when setting the time backwards has been at your > own risk for a long time. Yes, but there's really not much reason for it to be so much of a black art. Actually, I think the old behaviour, prior to rev 1.36, although not ideal was quite reasonable: it interpreted the user supplied date in the current time zone, say winter time, even though it refered to a period of summer time. It was that change that introduced a behaviour which IMHO must be regarded as a bug. > 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. Well, the line of code I objected to is not that old. CVS blames someone called ru on revision 1.36 who committed changes submitted by Crist Clark in 2001. > 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. There's not much point in doing that in this case, is there? All that is at stake here is if date translates from user supplied dates into a time_t in a predictable/justifiable manner. If it does/doesn't, rebooting and letting time pass won't do much good. The reason why I think that that must be seen as a bug is that date gave surprising results in a case where the user provided unmistakable input. Allow me to recall Eugene Grosbein / Holger Kipp's test case: > %setenv LC_ALL C > %setenv TZ Asia/Krasnoyarsk > %setenv unixtime 1193511599 > > %date -jr $unixtime > Sun Oct 28 02:59:59 KRAST 2007 > %date -jf %s $unixtime > Sun Oct 28 02:59:59 KRAT 2007 As you can see, the input to date is unmistakable, it is a time_t. The difference is that the second case forces date to use strptime() and the first doesn't. date is not outputing only the timezone wrong, those two dates are one hour appart. That means that in the first date is understanding 1193511599, and that in the second, at one point in its execution, date is understanding 1193615199, one hour latter. Trust me or add a printf to line 273. The line which is the cause for this misinterpretation is line 268. Before that line was introduced, behaviour was justifiable, although not ideal. If the user supplied unmistakable input, either a time_t or a date with explicit timezone, it worked, and when the user supplied date without timezone it always understood the date in the current timezone. This only had the inconvenient of +1/-1 when done across DST, but at least it wouldn't throw away the information supplied by the user. This line also makes date misinterpret full dates with timezone, not only time_ts for that limbo hour. In my opinion, we can have a bugless date for the limbo hour, and still solve the +1/-1 inconvenient simply by not destroying strptime()'s output. All it takes is to move 268 to line 191, as I said before. Of course, I don't think this is a critical or prioritary issue, not at all. It was only fun, because I could look into it in a half hour. But the kludge to solve the +1/-1 inconvenient is there and is ugly. Greetings Miguel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710312100.l9VL0tit006227>