From owner-freebsd-hackers Sat Jan 13 18:44:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from vieo.com (vieo.com [216.30.79.131]) by hub.freebsd.org (Postfix) with ESMTP id 889BD37B401 for ; Sat, 13 Jan 2001 18:44:12 -0800 (PST) Received: (from johng@localhost) by vieo.com (8.11.2/8.11.2) id f0E2i3518278; Sat, 13 Jan 2001 20:44:03 -0600 (CST) (envelope-from johng) Date: Sat, 13 Jan 2001 20:44:03 -0600 (CST) From: John Gregor Message-Id: <200101140244.f0E2i3518278@vieo.com> To: Gerhard.Sittig@gmx.net, leifn@neland.dk Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Cc: DougB@gorean.org, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message