Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Jan 2001 07:23:19 -0500
From:      Kevin Way <kway@wgate.com>
To:        Gerhard Sittig <Gerhard.Sittig@gmx.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Message-ID:  <20010103072319.B18615@way95.eng.tvol.net>
In-Reply-To: <20010102133239.V253@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Tue, Jan 02, 2001 at 01:32:39PM %2B0100
References:  <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet>

next in thread | previous in thread | raw e-mail | index | archive | help

--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I like these changes.

I'm definitely in favor of code that corrects for the DST handling=20
oddities that sysadmins have to deal with.  This would be especially=20
valuable for companies which might have deployments in 25 different=20
time zones globally, which for reasons that are out of scope can't
be converted to UTC.  The argument that the sysadmin should know the=20
results of putting a cronjob at a certain time become much weaker in=20
that scenario. =20

Additionally, the fact of the matter is that most DST crossovers
occur during low-usage periods for typical servers.  Given a choice of
performing resource-intensive daily chores at a time of low usage,
or wasting three hours each night, because twice a year there's a clock
jump, I'll take the fully utilized server please.

The one thing that has me giving some amount of hesitation, though=20
it's trivial, is the fact that this patch is based solely on clock skew.
My initial reaction is that I'd like the patch to check if the skew
has been caused by a time zone shift, though honestly, I can't think of
another scenario where a properly running server's clock would jump.

I'll gladly retract my endorsement of this type of change if somebody
can note scenarios where this could have negative effects equal to or
greater than the negative effects of the current system.

--=20
  kevin way <kway@wgate.com>
  worldgate communications
  software engineer
  +1 215 354 5287

--wac7ysb48OaltWcw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6Uxm3kHXCCwlJQwURAgneAJ4yMSejmX9z4vm4hMJM4wgi5VHxqwCcDs34
n+E9QS5RtneoCc9VM9BPTqA=
=MGll
-----END PGP SIGNATURE-----

--wac7ysb48OaltWcw--


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?20010103072319.B18615>