Date: Mon, 22 Jan 2001 21:37:56 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: Greg Black <gjb@gbch.net>, Neil Blakey-Milner <nbm@mithrandr.moria.org>, John Gregor <johng@vieo.com>, Gerhard.Sittig@gmx.net, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <3A6CEE84.21B5676F@bellatlantic.net> References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <nospam-3a6b44dfe00a3f3@maxim.gbch.net> <3A6B68E9.278A6BBB@bellatlantic.net> <200101212332.f0LNWun16287@earth.backplane.com> <3A6B82F5.43CA6A65@bellatlantic.net> <200101220635.f0M6ZbJ17648@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > > :> with your rather large diff set. For better or for worse, people > :> already know about the daylight savings shift problem. Thousands > :> of people depend on cron to work, which means that when you > :> make a major change like this it must be tested by a wider audience > :> for a longer time before becoming the default. It needs to have some > :> real-life operational experience behind it. > : > :This can be applied to whole FreeBSD just as well. And IMHO > :cron is less critical than any part of the kernel, yet changes > :to the kernel don't usually bring such a strong reaction. > > I think you have a valid argument in regards to cron vs the kernel. > But keep in mind that even though you are fixing a 'bug', it's a well > known 'bug' so you are in fact creating an operational change to the > code rather then just a bug fix or minor performance enhancement, etc... Yes, I understand that and I tried to make the change maximally compatible with the existing behavior. Even with all this I agree that making this change optional is a yet safer approach and by now I feel quite sorry that I did not take it from the start. > When I do major kernel work, it's usually tested by third parties for > a week or two. The last three major commits I've done had been under > test for three weeks (don't let the 2-5 day MFC fool you, I have to > do all my work on -stable first, then forward port to -current, then > MFC back to -stable). I never intended to MFC it immediately, that's why I said "in a few weeks" thus implying something like a month or so, possibly more. Also this change is not quite a major one. > :> This is broken. If you want to check for a DLS change there is only > :> one right way to do it, and that is to compare the wall clock > :> differential verses the GMT differential, and to not put in any silly > : > :I disagree. Checking the difference from GMT creates a danger > :of misrecognition of a time zone change (for example, when > :a machine was physically moved) for a DST switch. So comparing > :is_dst is the only reliable way to tell if there actually was > :such a switch. > > I don't consider someone changing the machine's /etc/localtime zone > to be an issue, since it rarely if ever happens. And if a machine is > moved, it's likely to be powered down anyway.... cron is not going to > nor is it supposed to 'catch up' after downtime. Additionally, cron > cannot detect a timezone change without being restarted, so the point > is moot anyhow. Agreed, this did not occur to me at once. Actually, after some thinking I see a reason why the difference from GMT may change without changing the DST state: if the country adopts different offset for its time zones, then the zoneinfo file would be updated in advance and cron would discover it on time. So comparing the difference really is the right way. And I think I see a simple way to do that and handling of arbitrary offsets as well. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A6CEE84.21B5676F>