:> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
