From owner-freebsd-doc@FreeBSD.ORG Thu Mar 22 14:10:13 2012 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86CE1065679 for ; Thu, 22 Mar 2012 14:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFEE8FC21 for ; Thu, 22 Mar 2012 14:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2MEADI1024028 for ; Thu, 22 Mar 2012 14:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2MEADoP024027; Thu, 22 Mar 2012 14:10:13 GMT (envelope-from gnats) Resent-Date: Thu, 22 Mar 2012 14:10:13 GMT Resent-Message-Id: <201203221410.q2MEADoP024027@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Florian k Unglaub Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C8271065670 for ; Thu, 22 Mar 2012 14:04:02 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4438FC1B for ; Thu, 22 Mar 2012 14:04:02 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q2ME41jg069417 for ; Thu, 22 Mar 2012 14:04:01 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q2ME411S069406; Thu, 22 Mar 2012 14:04:01 GMT (envelope-from nobody) Message-Id: <201203221404.q2ME411S069406@red.freebsd.org> Date: Thu, 22 Mar 2012 14:04:01 GMT From: Florian k Unglaub To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: docs/166318: Contradicting information in crontab(5) and cron(8) about DST X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:10:13 -0000 >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: