cron and DST (daylight saving time)

With the recent DST offset some of my cronjobs are running too early. I can change the scripts to handle the trigger myself but I think that would be cron's task in the first place. I haven't found that answer in the man page of cron or crontab... Does cron support triggering jobs with time entries defined in UTC? If not; are there any sensible options other than doing the job/time handling explicitly in my scripts? Thanks. Janis

This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards. --=_mimegpg-monster.email-scan.com-29721-1332693056-0001 Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Janis Papanagnou writes: > With the recent DST offset some of my cronjobs are running too early. > I can change the scripts to handle the trigger myself but I think that > would be cron's task in the first place. > I haven't found that answer in the man page of cron or crontab... > Does cron support triggering jobs with time entries defined in UTC? > If not; are there any sensible options other than doing the job/time > handling explicitly in my scripts? It depends on which cron you have. There are several different crons floating around various Linux distros. In Fedora 16, for example, which uses cronie, crontab(5) explains how to use the CRON_TZ environment variable. Other Linux distros may still use vixie-cron, and I don't remember what it does regarding this, if any. Check your cron's documentation for a definitive answer. --=_mimegpg-monster.email-scan.com-29721-1332693056-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk9vSEAACgkQx9p3GYHlUOIuKwCeIxepwYeUDH2Kd0VdjTHEPpiH pBMAn1ND2xQmV1hD5gL9E7rO/53RIdqw =/fD3 -----END PGP SIGNATURE----- --=_mimegpg-monster.email-scan.com-29721-1332693056-0001--

On 25.03.2012 18:30, Sam wrote: > Janis Papanagnou writes: > >> With the recent DST offset some of my cronjobs are running too early. >> I can change the scripts to handle the trigger myself but I think that >> would be cron's task in the first place. >> I haven't found that answer in the man page of cron or crontab... >> Does cron support triggering jobs with time entries defined in UTC? >> If not; are there any sensible options other than doing the job/time >> handling explicitly in my scripts? > > It depends on which cron you have. There are several different crons floating > around various Linux distros. In Fedora 16, for example, which uses cronie, > crontab(5) explains how to use the CRON_TZ environment variable. > > Other Linux distros may still use vixie-cron, and I don't remember what it > does regarding this, if any. Check your cron's documentation for a definitive > answer. Thanks for your quick reply! According to the man page my Xubuntu runs "Vixie Cron". The man pages do not mention CRON_TZ or any other related environment variables[*], though. Any other ideas? Janis [*] BTW, I think the time setting should be possible individually per cronjob, not for the whole cron user account. Otherwise it would not be possible to differentiate between jobs that require local time and jobs that want to trigger by coordinated time.

On 2012-03-25, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote: > On 25.03.2012 18:30, Sam wrote: >> Janis Papanagnou writes: >> >>> With the recent DST offset some of my cronjobs are running too early. cron runs at the time you tell it to run, using the local time zone to define the time. The time changed at 2AM this morning. So, when did you ask the system to run the jobs? >>> I can change the scripts to handle the trigger myself but I think that >>> would be cron's task in the first place. Well, what did you want the scripts to do? >>> I haven't found that answer in the man page of cron or crontab... >>> Does cron support triggering jobs with time entries defined in UTC? >>> If not; are there any sensible options other than doing the job/time >>> handling explicitly in my scripts? >> >> It depends on which cron you have. There are several different crons floating >> around various Linux distros. In Fedora 16, for example, which uses cronie, >> crontab(5) explains how to use the CRON_TZ environment variable. >> >> Other Linux distros may still use vixie-cron, and I don't remember what it >> does regarding this, if any. Check your cron's documentation for a definitive >> answer. > > Thanks for your quick reply! > > According to the man page my Xubuntu runs "Vixie Cron". The man pages > do not mention CRON_TZ or any other related environment variables[*], > though. > > Any other ideas? > > Janis > > [*] BTW, I think the time setting should be possible individually per > cronjob, not for the whole cron user account. Otherwise it would not > be possible to differentiate between jobs that require local time and > jobs that want to trigger by coordinated time.

This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards. --=_mimegpg-monster.email-scan.com-29721-1332705532-0005 Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Janis Papanagnou writes: > According to the man page my Xubuntu runs "Vixie Cron". The man pages > do not mention CRON_TZ or any other related environment variables[*], > though. If you've gone through the documentation, and you cannot find any mention of the timezone setting, then there simply isn't one, and your cron always uses your default system timezone, for all jobs. --=_mimegpg-monster.email-scan.com-29721-1332705532-0005 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk9vePwACgkQx9p3GYHlUOIHrACfTN53zo3067xMXmDD4K8LLEsx UR0An2T9haGcjPTShBTkuxnU6sCY3htD =ZLlj -----END PGP SIGNATURE----- --=_mimegpg-monster.email-scan.com-29721-1332705532-0005--

On 2012-03-25 20:03, Sam <sam@email-scan.com> wrote: > Janis Papanagnou writes: >> According to the man page my Xubuntu runs "Vixie Cron". The man pages >> do not mention CRON_TZ or any other related environment variables[*], >> though. > > If you've gone through the documentation, and you cannot find any mention of > the timezone setting, then there simply isn't one, and your cron always uses > your default system timezone, for all jobs. More likely it just means that cron relies on the system libraries to determine the time zone. On Linux this means that it will use the environment variable TZ if it exists and fall back to the system default (stored in /etc/localtime) otherwise So setting export TZ=UTC in the startup script of cron should cause cron to use UTC. However, it will then use UTC for all jobs, which may not be what you want. hp -- _ | Peter J. Holzer | Deprecating human carelessness and |_|_) | Sysadmin WSR | ignorance has no successful track record. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org

On 2012-03-25, Sam <sam@email-scan.com> wrote: > > Janis Papanagnou writes: > >> According to the man page my Xubuntu runs "Vixie Cron". The man pages >> do not mention CRON_TZ or any other related environment variables[*], >> though. > > If you've gone through the documentation, and you cannot find any mention of > the timezone setting, then there simply isn't one, and your cron always uses > your default system timezone, for all jobs. > AFAIK all crons use a single time zone whatever that might be. Basically, crond uses whatever timezone setting is in effect when it is launched/relaunched (eg after editing with crontab). Ie it makes an internal list of what to run an when at that launch time. As far as I know, it does not continually read the crontab file to figure out what to run at that time. It then used the timezone in effect at that time. Now, you could try to launch two cron daemons, with different crontab files and under two different timezones (eg one your local time and one UTC). I do not know if that would work.

This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards. --=_mimegpg-monster.email-scan.com-29721-1332711412-0009 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline unruh writes: > AFAIK all crons use a single time zone whatever that might be. > Basically, crond uses whatever timezone setting is in effect when it is > launched/relaunched (eg after editing with crontab). Ie it makes an > internal list of what to run an when at that launch time. As far as I > know, it does not continually read the crontab file to figure out what > to run at that time. It then used the timezone in effect at that time. No =E2=80=93 cronie, forked by RedHat from vixie-cron, can grok per-cront= ab =20 timezones, according to its documentation. Each user can specify the user= 's =20 crontab's timezone. --=_mimegpg-monster.email-scan.com-29721-1332711412-0009 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk9vj/QACgkQx9p3GYHlUOIioQCcCX+V0Vu/qIVrr1D/uD/YVVbK 2zcAn0fvN+lp9XsAWHkzY+dej5EqkJky =bm1y -----END PGP SIGNATURE----- --=_mimegpg-monster.email-scan.com-29721-1332711412-0009--

On 2012-03-25, Sam <sam@email-scan.com> wrote: > > unruh writes: > >> AFAIK all crons use a single time zone whatever that might be. >> Basically, crond uses whatever timezone setting is in effect when it is >> launched/relaunched (eg after editing with crontab). Ie it makes an >> internal list of what to run an when at that launch time. As far as I >> know, it does not continually read the crontab file to figure out what >> to run at that time. It then used the timezone in effect at that time. > > No =E2=80=93 cronie, forked by RedHat from vixie-cron, can grok per-cront= > ab =20 > timezones, according to its documentation. Each user can specify the user= > 's =20 > crontab's timezone. ??? So what? It was per entry timezone you wanted, not per user I thought. Yes, you might be able to do per crontab timezone, but not per line. As I suggested separate runs of cron might be able to handle different timezones, I am not sure.

On 2012-03-25, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote: > With the recent DST offset some of my cronjobs are running too early. > I can change the scripts to handle the trigger myself but I think that > would be cron's task in the first place. You mentioned that you have Vixie cron, which should almost certainly get its time from the system time. So perhaps your timezone is not configured correctly? You can double check your timezone and local time to see if that's the case. As a general rule I try to avoid scheduling any nonhourly jobs between 1am and 3am, just to make sure I avoid any irregularities with DST. --keith -- kkeller-usenet@wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information

On 25.03.2012 20:25, unruh wrote: > On 2012-03-25, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote: >> On 25.03.2012 18:30, Sam wrote: >>> Janis Papanagnou writes: >>> >>>> With the recent DST offset some of my cronjobs are running too early. > > cron runs at the time you tell it to run, using the local time zone to > define the time. The time changed at 2AM this morning. So, when did you > ask the system to run the jobs? Well, that's exactly the problem why I ask. I have to run some jobs at local time (CET and CEST) and some jobs at coordinated time (UTC). > > >>>> I can change the scripts to handle the trigger myself but I think that >>>> would be cron's task in the first place. > > Well, what did you want the scripts to do? I could trigger my jobs every hour (or so) then let my scripts decide (after a date or a date -u respectively) whether they exit immediately or do the intended job. But I don't want to let my scripts do another programs job; cron is specifically designed for time triggered tasks, so shifting (and multiplying) that effort to user programs is against the design spirit of Unixes, IMO. It's hard to imagine, though, that no one in four decades had such a [basic] requirement; so I am asking what I may have overlooked. Thanks. Janis > >>>> [...]

On 26.03.2012 06:21, Keith Keller wrote: > On 2012-03-25, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote: >> With the recent DST offset some of my cronjobs are running too early. >> I can change the scripts to handle the trigger myself but I think that >> would be cron's task in the first place. > > You mentioned that you have Vixie cron, which should almost certainly > get its time from the system time. So perhaps your timezone is not > configured correctly? You can double check your timezone and local time > to see if that's the case. TZ issues work all consistently and well on my system, including the CET/CEST switches. > > As a general rule I try to avoid scheduling any nonhourly jobs between > 1am and 3am, just to make sure I avoid any irregularities with DST. The problem is not so much the 02:00/03:00 switch - and yes, paranoid as I am I also avoid jobs in that time interval :-) - the problem is that I need CET/CEST and UTC triggered jobs both non-exclusively. From all the replies it seems that this is not supported and I will have to resort to other options. Thanks to all for your contributions to shed some light on the issue! Janis > > --keith > >

On 03/25/2012 12:02 PM, Janis Papanagnou wrote: > With the recent DST offset some of my cronjobs are running too early. > I can change the scripts to handle the trigger myself but I think that > would be cron's task in the first place. > I haven't found that answer in the man page of cron or crontab... > Does cron support triggering jobs with time entries defined in UTC? > If not; are there any sensible options other than doing the job/time > handling explicitly in my scripts? > > Thanks. > > Janis Maybe your version of cron didn't notice the change. Perhaps a simple stop and restart of crond will fix it?

On 2012-03-26, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote: > On 2012-03-25, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote: >> With the recent DST offset some of my cronjobs are running too early. >> I can change the scripts to handle the trigger myself but I think that >> would be cron's task in the first place. > > You mentioned that you have Vixie cron, which should almost certainly > get its time from the system time. So perhaps your timezone is not > configured correctly? You can double check your timezone and local time > to see if that's the case. I interpreted what he said that there are some jobs he wants run at the same UTC time every day, and others at the same local time. The latter were fine, the former of course shifted by an hour when DST came into effect, which he does not want. > > As a general rule I try to avoid scheduling any nonhourly jobs between > 1am and 3am, just to make sure I avoid any irregularities with DST. > > --keith > >

On 26.03.2012 15:36, Joe Beanfish wrote: > On 03/25/2012 12:02 PM, Janis Papanagnou wrote: >> With the recent DST offset some of my cronjobs are running too early. >> I can change the scripts to handle the trigger myself but I think that >> would be cron's task in the first place. >> I haven't found that answer in the man page of cron or crontab... >> Does cron support triggering jobs with time entries defined in UTC? >> If not; are there any sensible options other than doing the job/time >> handling explicitly in my scripts? >> >> Thanks. >> >> Janis > > Maybe your version of cron didn't notice the change. Perhaps a > simple stop and restart of crond will fix it? As mentioned, my cron did notice the CET/CEST switch. The problem was that I have to run some jobs at local time (CET and CEST) and some jobs at coordinated time (UTC). So I would need to specify something like 15 12 * * * utc-time_job-1 @UTC 30 23 * * * utc-time_job-2 @UTC 45 20 * * * local-time_job @localtime where the @UTC and @lokaltime are ad hoc and arbitrary syntax extensions, that in some way would have to be supported by cron but are not supported. In my example, the first two jobs would always run at the specified UTC time and would not be affected by DST switches (like CET/CEST), where the third job would run in local time and be affected by DST switches. The latter is how cron seems to work. I need support for both. Janis