Hi Chris,
        Please find comments in-line below.


>Date: Tue, 13 Feb 2007 20:42:42 +0000
>From: Chris Gerhard <chris at thegerhards.com>
>Don Cragun wrote:
>> Roland, 
>>      Thanks for bringing this to my attention.
>> Chris,
>>      The format shown in
>> http://blogs.sun.com/chrisg/entry/mutliple_time_zones_for_cron is not
>> allowed by the current standards.  The standards say that entries in
>> crontab files are of three types:
>> 1.  Blank lines  (i.e., spaces and tabs only terminated by a newline)
>> 2.  Comment lines (i.e., lines whose first non-blank character is '#')
>> 3.  The standard 6 field crontab entry specifying the minute, hour, day
>>     of month, month of year, day of week, and command to be executed by
>>     the shell.
>> So, lines like:
>> and
>> TZ=US/Pacific
>> are not allowed.
>>      But, since lines like:
>> # TZ=GMT
>> and
>> # TZ=US/Pacific
>> are allowed by the standard, you can do the same thing in a manner
>> compatible with the standard.
>However that could leads you to interpreting comments which would be bad.

Agreed.  I was not suggesting that this exact form is a good idea; only
that the standards allow comments in crontab files.

>Which standard would we be in breach of?

SVID3, POSIX.1-2001, POSIX.2-1988, XPG3, XPG4, SUS, SUSv2, SUSv3, ...

>It seems that the choices being offered are:
>1) Go with my suggestion. Which at least to me seems the most clear.
>2) Add the variables to comments which could lead to us interpreting 
>existing crontab files incorrectly if they already contain:
># TZ= ....
>and if we were to add other variables, HOME being one that would be 
>truly useful as I mentioned in another email in the thread. We end up 
>with a poorer user experience while complying to a standard that would 
>allow a customer to copy the crontab file to another system.

Adding anything to the crontab file is going to make it non-portable.
If the extension to the format can be done in comments in a manner that
is not likely to be confused with existing comments (and is not likely
to confuse a human unaware of this extension) then we still conform to
the standard and at least have comments that can be used to figure out
what needs to be changed when moving a crontab file to another system.

>Could we only allow the variables when using /usr/bin/crontab rather 
>than /usr/xpg[46]/bin/crontab ?

No.  Each version of crontab supports a subset of the standards listed
above.  Changing any of them violates one or more standards; picking
any one of them would just reduce the list of standards being

>>      For the record, I have also seen suggestions lately that $SHELL
>> should affect the shell used to run cron jobs.  The standard also says
>> that this is not allowed.  The values of $HOME, $LOGNAME, $PATH, $SHELL
>> and, although not explicitly mentioned, $TZ in the environment
>> inherited by crontab are not allowed to be used by default.  But this
>> can be done and still meet standards requirements by using
>> implementation specific extensions such as command line options.  I.e.,
>> the standard allows for option to be specified when crontab is invoked
>> to add a cron job.  So, something like:
>>              crontab [-H HOME_value] [-L LOGNAME_value] \
>>                      [-P PATH_value] [-S SHELL_value] \
>>                      [-T TZ_value] [file]
>> would be legal and the values specified could be stored as comments in
>> the crontab file.
>>      Note also that a lot of this can be done today with no changes
>> to cron or crontab.  You can set TZ in the environment of the command
>> to be executed using the following form:
>> * 8 * * * TZ=US/Eastern date > /tmp/out8
>> which will write a date stamp to the console every minute of the 8
>> o'clock hour of the local timezone displayed with US Eastern Time Zone
>> time stamps.  It is trickier when using subshells as in your example
>> where you would have to use:
>> * 8 * * * TZ=US/Eastern;export TZ;(/usr/bin/date ; /usr/bin/date -u) > 
>> /tmp/cron.out8
>> if you're using /usr/bin/crontab to add the job.  /usr/bin/crontab uses
>> a SVID3 compatible shell which does not support variable assignment in
>> an export statement.  If you're using /usr/xpg4/bin/crontab or
>> /usr/xpg6/bin/crontab, the same crontab entry could be written as:
>> * 8 * * * export TZ=US/Eastern;(/usr/bin/date ; /usr/bin/date -u) > 
>> /tmp/cron.out8
>>      Whether you would want to use this form obviously depends on
>> whether you want the time at which the command will be executed and the
>> output of commands run to be controlled by the alternate TZ setting, or
>> you just want the output of the commands run to be controlled by the
>> alternate TZ setting.
>The TZ actually needs to work on within cron so that the time of the 
>event is run at the correct time according to that timezone.

I agree that this is the most common case.  If you have a job that is
to run once every hour, the trick suggested above may be sufficient in
timezones that are full hours off of GMT.

>The extra variables are potentially useful when they effect cron.  TZ & 
>HOME and to a lesser degree SHELL & PATH (since you can do this with a 
>script). I fail to see the usefulness of allowing the setting of LOGNAME 
>since cron would clearly not honour this.

The cron daemon isn't honoring any of these, the question is what the
invoked command will see in the environment after it is invoked by the
shell cron starts.


Reply via email to