Date: Thu, 22 Mar 2012 14:04:01 GMT From: Florian k Unglaub <f.unglaub@googlemail.com> To: freebsd-gnats-submit@FreeBSD.org Subject: docs/166318: Contradicting information in crontab(5) and cron(8) about DST Message-ID: <201203221404.q2ME411S069406@red.freebsd.org> Resent-Message-ID: <201203221410.q2MEADoP024027@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203221404.q2ME411S069406>