[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Roland Mainz]

On 2/14/07, Richard Lowe  wrote:
> Don Cragun wrote:
> > Roland,
> >   Thanks for bringing this to my attention.
> >
> > Chris,
> >   The format shown in
>
> [... huge amount of snipping ...]
>
> This conversation is still happening on request-sponsor, which is a tool,
> not a discussion list.  Could it please be diverted to opensolaris-rfe or
> the like, where it belongs?

Please move the discussion to shell-discuss at opensolaris.org - AFAIK
that is the closest match in this case.

As possible solution (I don't have the manual pages around) the
environment variables could be used. AFAIK (POSIX) cron allows it to
add variable definitions in the form of  =  at the
beginning of the crontab file. If this is really allowed we could
follow ksh93's approach to compound variables (please read
http://www.opensolaris.org/os/project/ksh93-integration/docs/ksh93r/man/man1/sh/
- the syntax should follow POSIX shell+crontab rules, including
quoting etc.) and use a variable like ".cron.timezone" (note the '.'
at the beginning) as variable name to define a timezone per line
(please do not use something like ".cron.TZ", uppercase names should
be avoided to prevent confusion with environment variables defined
here and long variable names do not hurt anyone).

This would allow setting "cron"-specific settings for the following
lines and provide an easy mechanism for future extensions of the
crontab without creating some format and/or parser nightmare.

Anyway... please move the discussion to shell-discuss at opensolaris.org
if possible...



Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Chris Gerhard]

While researching this I came across this thread from 2005 which has a 
similar conversation.

Titled "extended crontab syntax" in the rfe list:

http://www.opensolaris.org/jive/thread.jspa?threadID=2941&start=0&tstart=0

However that thread appears to have stalled when a whole new scheduling 
framework was suggested. Which would support my contention that 
modifying cron is a realistic approach to make a real difference.

--chris

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Richard Lowe]

Don Cragun wrote:
> Roland, 
>   Thanks for bringing this to my attention.
> 
> Chris,
>   The format shown in

[... huge amount of snipping ...]

This conversation is still happening on request-sponsor, which is a tool, 
not a discussion list.  Could it please be diverted to opensolaris-rfe or 
the like, where it belongs?

-- Rich

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[James Carlson]

Don Cragun writes:
> >> # 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.

They don't allow the comments to be interpreted.

More importantly, though, this still wouldn't be portable.  If we did
this, then crontab files created on Solaris that use this new
construct would *NOT* be interpreted correctly if copied over to some
other system.

Yes, the "comments" would be ignored, but the resulting crontab file
would be misinterpreted: the time zone would not be adjusted for the
entries that follow, and thus it'd fail to start the jobs when the
user expected them to be started.

So, merely changing these things into comments is not a solution to
the portability problem.

> >Which standard would we be in breach of?
> 
> SVID3, POSIX.1-2001, POSIX.2-1988, XPG3, XPG4, SUS, SUSv2, SUSv3, ...

I think it's much simpler to say something like this:

Solaris supports a proper superset of the standards listed
below.  The user can choose to add "=" lines
to his crontab(4) file.  If he chooses to do so, then his
crontab will not be in compliance with those standards, and
may not be portable to other operating systems that support
only those standards.

Crontab(4) files that are in compliance with those standards
will always work properly on a Solaris system.

In other words, just as it is with adding (say) /opt/csw/bin to your
$PATH, it's the user's choice whether he wants to walk outside the
standards.  He doesn't have to.

-- 
James Carlson, Solaris Networking  
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Chris Gerhard]

Don Cragun wrote:
> 
> Note that if installing an application adds a crontab entry to root's
> crontab file, you probably don't want that entry to be shifted several
> hours by a prior non-standard entry in the original crontab file.

Ah well there are already lots of assumptions here.  The first being 
that the systems timezone will match the geographic timezone or what 
ever timezone the application intended in some way. For a global system 
the choice of timezone is somewhat arbitrary.

Hence the desire to be able to explicitly state the timezone of entries 
in the crontab.

> Wouldn't it be better if setting the TZ value only applied to a single
> following entry rather than to all following entries?
> 

IMO no.  If a user wants this then they can list the TZ or any other 
variable above each line.

--chris

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Chris Gerhard]

Thanks Don,

Comments in line

Don Cragun wrote:
>> 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.

O.k.

However the 
http://www.opengroup.org/onlinepubs/009695399/utilities/crontab.html states:

Blank lines and those whose first non-  is '#' shall be ignored.

So interpretting the comments would be in breach of the standard as well.

> 
>> 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
> violated...

Adding a new one?

/usr/tz/bin/crontab ?

(the path is just an example, I personally dislike this).

All the existing crontab commands would adhere to the standard. If you 
wish to use the extension you use a different crontab command.

Or would we be allowed to have a setting in /etc/default/cron ?

ALLOW_VARIABLES=yes

If set you can have the new functionality if not you get the standards 
conforming.


>> 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.

Not very useful as that does not do day light saving and certainly not 
as nice as just setting the timezone.

> 
>> 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.
> 

Actually the modified cron daemon is honouring the TZ. Having it honour 
HOME as well so that it does not chdir to a directory that may not be 
available (typically due to issues with secure forms of NFS) would also 
be a good thing.

--chris

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Chris Gerhard]

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:
> TZ=GMT
> 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.

Which standard would we be in breach of?

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.

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


>   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.

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.

--chris

-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL: 

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Mike Gerdts]

On 2/13/07, Don Cragun  wrote:
> 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.

A read of the crontab man page for UNIX 03 at unix.org suggests the following:

1) The file format presented via an editor to crontab(1) is fixed.
2) How the file is stored is not defined.
3) The definition of how the time is interpreted is not defined.

As such, it seems as though the additional options listed above could
be stored in /var/spool/cron/crontabs/user.cfg (or similar) to be
created to hold these extra values.  Last time I checked, similar
auxiliary files are created when BSM auditing is enabled (user.au), so
there is a precedent for adding extra files in that directory.

Mike

-- 
Mike Gerdts
http://mgerdts.blogspot.com/

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Don Cragun]

Hi Mike,
Please find comments in-line below.

Cheers,
Don

>Date: Tue, 13 Feb 2007 17:26:50 -0600
>From: Mike Gerdts 
>X-PMX-Version: 5.2.0.264296
>
>On 2/13/07, Don Cragun  wrote:
>> 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.
>
>A read of the crontab man page for UNIX 03 at unix.org suggests the following:
>
>1) The file format presented via an editor to crontab(1) is fixed.
>2) How the file is stored is not defined.
>3) The definition of how the time is interpreted is not defined.
>
>As such, it seems as though the additional options listed above could
>be stored in /var/spool/cron/crontabs/user.cfg (or similar) to be
>created to hold these extra values.  Last time I checked, similar
>auxiliary files are created when BSM auditing is enabled (user.au), so
>there is a precedent for adding extra files in that directory.

The current proposal wants the setting of TZ to apply to all lines
following it in the crontab file and allows TZ to be set differently
for different lines in the crontab file.  Using something like
/var/spool/cron/crontabs/user.cfg is only appropriate if it applies to
all lines in that user's crontab file.

Note that if installing an application adds a crontab entry to root's
crontab file, you probably don't want that entry to be shifted several
hours by a prior non-standard entry in the original crontab file.
Wouldn't it be better if setting the TZ value only applied to a single
following entry rather than to all following entries?

>
>Mike
>
>-- 
>Mike Gerdts
>http://mgerdts.blogspot.com/

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Don Cragun]

Hi Chris,
Please find comments in-line below.

Cheers,
Don

>Date: Tue, 13 Feb 2007 20:42:42 +
>From: Chris Gerhard 
>
>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:
>> TZ=GMT
>> 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
violated...

>
>
>>  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, t

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[James Carlson]

Don Cragun writes:
>   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

That doesn't look too useful to me.

The problem is that crond itself runs in the default time zone of the
system itself, rather than in the time zone of the user.  This means
that the first five columns (and the second one in particular) are
just plain "wrong" for remote users.

>   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 former.  The latter is just a helpful side-effect of the proposed
feature.

-- 
James Carlson, Solaris Networking  
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Don Cragun]

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:
TZ=GMT
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.
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.

Cheers,
Don

>Return-Path: 
>Date: Sat, 10 Feb 2007 00:57:00 +0100
>From: Roland Mainz 
>Subject: Re: [request-sponsor] request sponsor for 6518038: cron & 
crontabshould support multiple timezones
>To: Darren J Moffat 
>Cc: Chris Gerhard , request-sponsor at 
>opensolaris.org, Don 
Cragun 
>MIME-version: 1.0
>Content-transfer-encoding: 7BIT
>X-Accept-Language: en
>X-PMX-Version: 5.2.0.264296
>
>Darren J Moffat wrote:
>> Chris Gerhard wrote:
>> > I have a working prototype which I have documented here:
>> >
>> > http://blogs.sun.com/chrisg/entry/mutliple_time_zones_for_cron
>> >
>> > Since this is not part of my day job, I'm requesting a sponsor despite
>> > being a Sun employee so I can do this on my own time.
>> 
>> Chris is local to me (physically and timezone :-) I hope that we can
>> present the full process at a future LOSUG  and given this needs ARC
>> review I'll sponsor the ARC case and the putback for this.
>
>Two items:
>1. Is it possible to sync with the POSIX people whether the change is
>legal for XPG4/XPG6, please (CC:'ing Don Cragun for that) ?
>2. Somewhere in my queue is support for sub-minute timing in cron...
>would it be usefull to add this in one step with this patch, too ?
>
>
>
>Bye,
>Roland
>
>-- 
>  __ .  . __
> (o.\ \/ /.o) roland.mainz at nrubsig.org
>  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>  /O /==\ O\  TEL +49 641 7950090
> (;O/ \/ \O;)

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Chris Gerhard]

Roland Mainz wrote:
> Darren J Moffat wrote:
>> Chris Gerhard wrote:
>>> I have a working prototype which I have documented here:
>>>
>>> http://blogs.sun.com/chrisg/entry/mutliple_time_zones_for_cron
>>>
>>> Since this is not part of my day job, I'm requesting a sponsor despite
>>> being a Sun employee so I can do this on my own time.
>> Chris is local to me (physically and timezone :-) I hope that we can
>> present the full process at a future LOSUG  and given this needs ARC
>> review I'll sponsor the ARC case and the putback for this.
> 
> Two items:
> 1. Is it possible to sync with the POSIX people whether the change is
> legal for XPG4/XPG6, please (CC:'ing Don Cragun for that) ?
> 2. Somewhere in my queue is support for sub-minute timing in cron...
> would it be usefull to add this in one step with this patch, too ?
> 

Ah, some more feature creep!

I'll add it to the list I emailed to Darren privately:

> 
> There is a small danger of feature creep here, but since I'm adding the TZ 
> environment variable I wondered if there are any other things a user should 
> be able to configure.
> 
> The ones that sprang to mind are:
> 
> HOME Let users choose an alternative home directory. I've wanted this in the 
> past when using secure NFS for my home directory but still wanting cron to 
> work. No workaround currently.
> 
> SHELL Let uses choose a shell other than bourne shell to execue the commands. 
> I'm less convinced about this as you can always exec a shell script but many 
> customers have requested this.
> 
> PATH Let users reset the path.  Again a shell script.
> 
> EMAIL Let users specify an alternative email address.   Again a pipe will 
> solve this already.
> 


Sub minute support. Workaround: sleep N && .

The two that seem to be most important are the original timezone RFE and 
HOME as neither of these can effectively be worked around. Though all 
the others variables are easy.  Sub minute to a second accuracy would 
only really be hard in that finding a syntax that kept backward 
compatibility and was sane would need a bit of thought researching.


--chris
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL: 

[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones

[Roland Mainz]

Darren J Moffat wrote:
> Chris Gerhard wrote:
> > I have a working prototype which I have documented here:
> >
> > http://blogs.sun.com/chrisg/entry/mutliple_time_zones_for_cron
> >
> > Since this is not part of my day job, I'm requesting a sponsor despite
> > being a Sun employee so I can do this on my own time.
> 
> Chris is local to me (physically and timezone :-) I hope that we can
> present the full process at a future LOSUG  and given this needs ARC
> review I'll sponsor the ARC case and the putback for this.

Two items:
1. Is it possible to sync with the POSIX people whether the change is
legal for XPG4/XPG6, please (CC:'ing Don Cragun for that) ?
2. Somewhere in my queue is support for sub-minute timing in cron...
would it be usefull to add this in one step with this patch, too ?



Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)