Date: Sat, 13 Jan 2001 20:44:03 -0600 (CST) From: John Gregor <johng@vieo.com> To: Gerhard.Sittig@gmx.net, leifn@neland.dk Cc: DougB@gorean.org, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <200101140244.f0E2i3518278@vieo.com> In-Reply-To: <Pine.BSF.4.21.0101132304570.49081-100000@arnold.neland.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
<delurk> Ok, this has gone on long enough that my normal inhibitions about driving down the signal-to-noise ratio of a technical list have long subsided. Folks, cron is a *LOW LEVEL SERVICE* much in the same vein as UDP. Neither one makes strong guarantees about ordering, duplication, or dropped events. Those are for higher layer services, iff they are needed. *BSD may very well have a need for a temporal equivalent to TCP where stronger guarantees are made, but it is not and should not be cron. That said, I can't help dinking with the design :-) What would happen if the definitions of the hour and minute fields were subtly changed to mean "elapsed wall-clock time since local midnight"? Then, the DST conversion is no longer ambiguous. "Two hours since local midnight" only happens once regardless. On days where the clocks change, most scripts would wind up running an hour ahead or behind their usual time, but hey, so are many of the people :-). There would also have to be an entry in the BUGS section noting that some days have 23 or 25 hours, which is accurate. -JohnG </delurk> 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?200101140244.f0E2i3518278>