Date: Sun, 04 Mar 2001 17:30:00 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Doug Barton <DougB@FreeBSD.org> Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org>, Matt Dillon <dillon@earth.backplane.com>, John Gregor <johng@vieo.com>, Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.org, gjb@gbch.net, Kevin Way <kway@wgate.com> Subject: cron and daylight time - revisited Message-ID: <3AA2C1E8.85E6B318@bellatlantic.net> 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> <3A6B46DF.7BE84F45@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
All, I have produced another version of the time zone changes in cron. I ran a few tests and plan to commit it to -current after a bit more testing. Everyone who wants to join the testing efforts is welcome. The comments are welcome as well. The new behavior is enabled by the option "-s", without this option the old behavior is preserved. The files are available from http://people.freebsd.org/~babkin/cron/ cron.df - context diff ct - my test crontab testdst - the test script called from this crontab dst_st.log - log of switch-over from summer time to winter time st_dst1.log - log of switch-over from winter time to summer time, with cron resterted before 1:00 st_dst2.log - log for the same switch but with cron resterted at 1:58 The logic is generally the same as in my previous attempt (see cron.8 version 1.13 in the CVS tree) with the following differences: - new option "-o" that enables the old behavior. This behavior is default now but it makes a pre-defined way to guarantee the same behavior in future in case if the default would change. - no more limitation of one-hour granularities for the time zone changes - handling of the ends ranges which fall into a disappearing time interval is more complicated. Sa can be seen from the st_dst* logs they depend on whether these jobs actually ran within one hour before the disappearing interval. So the crontab line 0 1-2 * * * /home/cron/testdst at one to two range OCLOCK as well as its equivalent 0 1,2 * * * /home/cron/testdst at one to two range OCLOCK on a switch from 2:00 ST to 3:00 DST would not normally run because it ran an hour ago, so it falls under the general ranges rule (see cron(8)) and does not run at 3:00DST (which is the same as 2:00ST). But if cron was restarted or crontab reloaded between 1:00 and 2:00 then this knowledge would be lost and the command would be executed at 3:00DST as well. I don't quite like that but I see no easy and efficient way to check if some command would have run within an hour before its next scheduled run. This time is a fixed hour rather than the difference in offset from GMT because all the commands in cron run by hours (possibly, at multiple minute values, but all the minute values repeat for all the listed hour values). -SB 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?3AA2C1E8.85E6B318>