Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)

[John Gregor]

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