Messages in this thread | | | Date | Mon, 19 Oct 1998 14:29:22 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: bug introduced in 2.0.34 |
| |
From aeb Mon Oct 19 00:56:11 1998
From alan@lxorguk.ukuu.org.uk Sun Oct 18 21:54:38 1998
> For everybody who does not fiddle explicitly with this tz_dsttime field > it is zero, so if the kernel uses it it makes no difference at all. > Let us grep for tz_dsttime in 2.0.35:
Then explain why people with hour difference problems in SMB found they went away when it was changed to use that.
Well, I would like to see such a person. I am not aware of software that fiddles with this field.
Following up on my own mail - software that treats tz_dsttime as a daylight saving time flag cannot be Berkeley software or GNU software so is most likely Linux-only software. By some coincidence I maintain util-linux, and yesterday night I checked the most likely culprits, and date, hwclock on RedHat 5.1 and clock on TAMU did not contain this particular flaw.
However, clock was patched to do precisely this, and util-linux has contained this patched version of clock for a long time (between util-linux-1.6 and util-linux-2.6). Moreover, util-linux-2.6 is still used by SuSE 5.3.
So, I withdraw my scepticism, it is true that there is such buggy software around, but of course still maintain that the kernel should be fixed.
Best regards, Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |