docs/166318: Contradicting information in crontab(5) and cron(8) about DST

[Florian k Unglaub]

>Number:         166318
>Category:       docs
>Synopsis:       Contradicting information in crontab(5) and cron(8) about DST
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 22 14:10:13 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Florian k Unglaub
>Release:        9.0 RELEASE
>Organization:
none
>Environment:
FreeBSD mars 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
The crontab(5) man page clearly states that jobs scheduled in the lost hour from winter to summer time are lost and are executed twice in the summer to winter transition. 


BUGS
     If you are in one of the 70-odd countries that observe Daylight Savings
     Time, jobs scheduled during the rollback or advance will be affected.  In
     general, it is not a good idea to schedule jobs during this period.
     
     For US timezones (except parts of IN, AZ, and HI) the time shift occurs
     at 2AM local time.  For others, the output of the zdump(8) program's ver?
     bose (-v) option can be used to determine the moment of time shift.


However, cron(8) states that jobs scheduled between 2AM and 3AM are executed correctly if cron is started with the "-s" switch (which is the default).

Relevant parts from cron(8):


     -s      Enable special handling of situations when the GMT offset of the
             local timezone changes, such as the switches between the standard
             time and daylight saving time.

             The jobs run during the GMT offset changes time as intuitively
             expected.  If a job falls into a time interval that disappears
             (for example, during the switch from standard time) to daylight
             saving time or is duplicated (for example, during the reverse
             switch), then it is handled in one of two ways:

             The first case is for the jobs that run every at hour of a time
             interval overlapping with the disappearing or duplicated inter?
             val.  In other words, if the job had run within one hour before
             the GMT offset change (and cron was not restarted nor the
             crontab(5) changed after that) or would run after the change at
             the next hour.  They work as always, skip the skipped time or run
             in the added time as usual.

             The second case is for the jobs that run less frequently.  They
             are executed exactly once, they are not skipped nor executed
             twice (unless cron is restarted or the user's crontab(5) is
             changed during such a time interval).  If an interval disappears
             due to the GMT offset change, such jobs are executed at the same
             absolute point of time as they would be in the old time zone.
             For example, if exactly one hour disappears, this point would be
             during the next hour at the first minute that is specified for
             them in crontab(5).

/usr/src/usr.sbin/cron/cron.c states clearly in lines 210 ff. that the behaviour follows the cron(8) description.
>How-To-Repeat:

>Fix:
Remove the BUGS section in crontab(5)

>Release-Note:
>Audit-Trail:
>Unformatted: