From owner-freebsd-hackers Sun Jan 21 22:36: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3510537B402 for ; Sun, 21 Jan 2001 22:35:44 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0M6ZbJ17648; Sun, 21 Jan 2001 22:35:37 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Jan 2001 22:35:37 -0800 (PST) From: Matt Dillon Message-Id: <200101220635.f0M6ZbJ17648@earth.backplane.com> To: Sergey Babkin Cc: Greg Black , Neil Blakey-Milner , John Gregor , Gerhard.Sittig@gmx.net, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) 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> <3A6B68E9.278A6BBB@bellatlantic.net> <200101212332.f0LNWun16287@earth.backplane.com> <3A6B82F5.43CA6A65@bellatlantic.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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... 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). :> So I have to say here that I agree with the calls to back it out... :> it needs to backed out, and then put back in as a command line option. :> Or you need to commit the command line option code ASAP and make the :> old behavior the default. Judging by the diffs, it should not be :> difficult for you to do this. : :OK, I'll change it to a command line option. I sure would appreciate it. Thanks! :> 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. -Matt :This limitation stems from the way the Vixie cron works. Supporting :other sorts of DST timing is either non-obvious or would require :a complete rewrite of cron to make it work like in SVR4, by :precalculating the time_t time of next run for each job in advance. :Such a rewrite would nicely fix the problem of missed minutes under :high load as well but will require significant effort to do :and lots of testing. : :Anyway, the present limitation covers most of the globe nowadays except :for Kirgizia and a few islands in Australasia (judging from the :zoneinfo files). If the fix in its present form would be accepted :then I guess adding more code around it for half-an-hour and arbitrary :DST timing would be the next step. : :-SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message