(Migrated) cron syntax + TZ

Community support
#1

(This message has been automatically imported from the retired mailing list)

Hello,

I’m trying to figure out how best to tackle updating a cron-style job’s
definition between time-zones in terms of GUI, how to make it most
convenient to use. Would appreciate your input.

We’ve got two fields:

  • Start time
  • Definition itself

Start time is always in a user’s timezone and there is nothing to change
on this front.

However, let’s say we are UTC+4 and the definition is:

  • 2 * * *

Which is - each minute, between 02:00-02:59, each day of month, each
month, each day of week.

Now its canonical version in UTC would be * 22 * * * and the start time
would ensure the correct 22 hours were used to fire a job the first time.

If now the user changes the TZ to UTC-7 the definition would on GUI read

  • 15 * * * (still * 22 * * * internally).

Things begin to look interesting if time spans and days of week or month
are added.

Again, a user in UTC+4 defines 15 2-5 * * 5 - which is:

  • Each month
  • Each day of month
  • Only Fridays
  • At 02:15, 03:15, 04:15 and 05:15

In UTC this becomes:

  • Each month
  • Each day of month
  • Either on Thursdays 22:15 and 23:15 or on Fridays 00:15 and 01:15

Trouble is, I’m not even sure if for the purposes of being displayed in
web-admin this can be converted into a single valid cron expression in

  • Cron as such
  • The crontab library we are using under the hood

Same would go for similar cases that straddle boundaries between days or
months.

The promise is to support a wide range of expressions so I wouldn’t want
to limit what the scheduler can handle.

For 2.1, I’m considering the addition of a separate field to cron-style
jobs that would indicate the TZ a given definition is in.

By default, when a job is created, it would be set to the user’s
selected TZ.

But if a user’s time-zone got changed, the definition’s TZ would not
change so as not to end up with a definition we cannot express.

What do you think? Would everyone be satisfied with such an approach?

thanks,

#2

Hi Dariusz

You are going to have a problem if you don’t schedule based on the users TZ
the minute daylight savings comes into effect.

Hello,

I’m trying to figure out how best to tackle updating a cron-style job’s
definition between time-zones in terms of GUI, how to make it most
convenient to use. Would appreciate your input.

We’ve got two fields:

  • Start time
  • Definition itself

Start time is always in a user’s timezone and there is nothing to change
on this front.

However, let’s say we are UTC+4 and the definition is:

  • 2 * * *

Which is - each minute, between 02:00-02:59, each day of month, each
month, each day of week.

Now its canonical version in UTC would be * 22 * * * and the start time
would ensure the correct 22 hours were used to fire a job the first time.

If now the user changes the TZ to UTC-7 the definition would on GUI read

  • 15 * * * (still * 22 * * * internally).

Things begin to look interesting if time spans and days of week or month
are added.

Again, a user in UTC+4 defines 15 2-5 * * 5 - which is:

  • Each month
  • Each day of month
  • Only Fridays
  • At 02:15, 03:15, 04:15 and 05:15

In UTC this becomes:

  • Each month
  • Each day of month
  • Either on Thursdays 22:15 and 23:15 or on Fridays 00:15 and 01:15

Trouble is, I’m not even sure if for the purposes of being displayed in
web-admin this can be converted into a single valid cron expression in

  • Cron as such
  • The crontab library we are using under the hood

Same would go for similar cases that straddle boundaries between days or
months.

The promise is to support a wide range of expressions so I wouldn’t want
to limit what the scheduler can handle.

For 2.1, I’m considering the addition of a separate field to cron-style
jobs that would indicate the TZ a given definition is in.

By default, when a job is created, it would be set to the user’s
selected TZ.

But if a user’s time-zone got changed, the definition’s TZ would not
change so as not to end up with a definition we cannot express.

What do you think? Would everyone be satisfied with such an approach?

thanks,

–
Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and Cloud Integrations in Python

#3

On 19/03/15 23:41, Tim Hoffmn wrote:

You are going to have a problem if you don’t schedule based on the users
TZ the minute daylight savings comes into effect.

DST… Right… The usage pattern would be probably something like here:

  • One logs into web-admin
  • Sets their location to Europe/Luxembourg
  • Adds a cron-style job
  • Realizes it was a typo, their location should have been Antarctica/Rothera

Now the job is still in Europe/Luxembourg so it’s DST-aware but it’s DST
of Luxembourg it works with.

Or:

  • One logs into web-admin
  • Doesn’t set any TZ meaning it defaults to UTC
  • Adds a cron-style job
  • Realizes their location should have been Antarctica/Rothera

And no DST of Antarctica is taken into account at all either.

How about displaying a note if there are any cron-style jobs that need
be updated after users change their preferred TZ and the new one is not
what any of the jobs uses?

This would have to be a note only, not an error, because if you are in
Antarctica/Rothera and I am in Luxembourg I don’t want to update any
jobs only because we have different TZs.

Plus, when listing scheduler jobs - if it’s a cron-style one, display
its TZ in the listing.

#4

Dariusz,

This is an extremely confusing issue, but I’m glad you’re tackling it.

I think the underlying problem here is that cron almost always uses UTC
time, because UTC time is the default system clock on most Linux systems,
and there is not an easy TZ parameter you can pass in when scheduling jobs.

I know in Ubuntu you can set the system clock to be local time, but it is
not recommended. I’m not familiar with how Zato uses cron, but what if it
runs on a system that uses local time instead of UTC for the system clock?

Without making cron TZ-aware, or without using a cron library that is
TZ-aware, any approach using something other than UTC will be very
complicated, and very confusing to the user. How would you even allow users
to create cron definitions in their local TZ if crontab uses UTC? Will you
convert it to UTC on the back-end, but display the local time in the GUI?
What happens when DST kicks in - will you update the existing jobs
automatically?

On Fri, Mar 20, 2015 at 4:42 AM, Brian Candler b.candler@pobox.com wrote:

On 20/03/2015 07:36, Dariusz Suchojad wrote:

How about displaying a note if there are any cron-style jobs that need
be updated after users change their preferred TZ and the new one is not
what any of the jobs uses?

It seems to me that in this context, “user’s preferred TZ” actually means
a single system-wide setting, not a per-user setting. That is, if I
understand right, the configuration is something like:

[system timezone, [set of cron rules]]

I think this could be improved by making the cron engine have its own
timezone setting:

[cron timezone, [set of cron rules]]

This would allow you to specify your cron rules in a particular timezone,
or UTC, regardless of the the system default. It would also allow different
users to have their own display timezones without affecting cron.
Furthermore, if the user or system default timezone changes, it doesn’t
require any automatic changes to the cron rules.

Taking this to its conclusion, the most flexible approach would be if each
individual rule were tagged with a timezone:
[[timezone, cron rule]]

Then you could have a rule like:
“mail this report out to my customers in India at 3pm every Friday, India
time”

Cheers,

Brian.