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

[Matt Dillon]

    If someone wants to tackle this, a few words to the wise.

    * testing for daylight savings times changes.  You test this by comparing
      the differential between two time_t's (dtime1) against the differential
      between two time_t's after converting them to localtime and then back
      to time_t's as if the localtime structure were in GMT (dtime2).

      If dtime1 has a large differential the clock was stepped and all 
      daylight savings specific state must be ignored and/or reset.

      If dtime1 is reasonable and (dtime2 - dtime1) shows a large
      differential (e.g.  20 minutes or greater), you hit a daylight savings
      switch and can use this to drive your state logic.

      Make sure your code is robust enough to ignore leap seconds and other
      minor corrections that cron already deals with.

      Encapsulate the state machine for handling daylight savings shifts
      into a single procedure if you can.  Do not spread special cases all
      over the codebase.  Don't worry about making lots of calls to the libc
      time conversion routines if it makes your job easier.

    * cron is a critical system resource.  Don't blow it.  For example,
      for many many years Vixie cron had horrendous bugs in it that would
      for example cause it to try to 'catch up' on time steps, resulting
      in systems suddenly running hundreds of cron jobs simultaniously.

      (this and other bugs were what prompted me to write dcron for Linux
      a number of years ago).

      Whatever you do, don't ressurect old bugs!

    All of that said, if someone wants to tackle this issue in cron, I think
    it would be great.  Having written a cron program before I would be happy
    to review the patchsets. 

                                                    -Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message