Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am looking for a cron replacement (or a method in cron if at all possible) that can allow for the scheduling of jobs in any number of time zones (specifically more than one per user/file). What I would like is the ability to specify a time zone per job (or cron line), and then only specify times in local times zones. I notice that I can change the entire time zone cron runs in, but at the end of the day it can only run in one time zone.

My current solution is to convert all my times to GMT and runs jobs accordingly, the only issue is during daylight savings changeover weeks, many manual edits must be done in order to make sure things run correctly in the respective local time zone (for example some regions do not follow daylight savings, or they do not change at the same date).

Any thoughts on this?

share|improve this question

5 Answers 5

up vote 2 down vote accepted

I think you're trying to have it both ways and the reality is that you just can't. If you want a job to run at 8 AM local time, for example, regardless of whether daylight saving is active then you either run your system (and cron) in local time and don't do seasonal edits or you run it in UTC (not GMT) and do seasonal edits. If you want your jobs to run at the same UTC, regardless, then you run cron according to UTC and there's nothing more to do.

If what you want is for a user to be able to schedule a cron job according to his local time zone and not have him have to think about conversions for his convenience then you write a conversion script that accepts a cron spec and a time zone then does the conversion to UTC behind the scenes and edits the crontab for him. It could even be a two-way conversion to handle changes to existing entries.

It will be helpful if you tell us what you're actually trying to accomplish.

share|improve this answer

fcron supports this feature.

From the documentation of the "timezone" option in fcrontab(5):

Run the job in the given time zone. timezone-name is a string which is valid for the environment variable TZ: see the documentation of your system for more details. For instance, "Europe/Paris" is valid on a Linux system. This option handles daylight saving time changes correctly. The TZ environ,ment variable is set to the value of timezone when a job defining this option is run.

share|improve this answer

Cfengine is the way we do this. You can set up jobs using local time (which adapts to daylight savings) or GMT for simultaneous jobs. You can create any kind of custom calendar, with exceptions. I know you can pay a tonne of money for scheduling software but we never needed anything more than this, even with datacentres in 3 locations around the world.

share|improve this answer

You could write yourself a little wrapper that takes three args:

  • Target timezone hour to match
  • Target timezone
  • Command to run if target tz hour matches current hour (in target tz).

Then just put that wrapper line in your crontab to run hourly:

python tz_wrapper.py 14 "US/Mountain" "echo 'hi'"

Simple python version:

#!/usr/bin/python
import sys, os, datetime
import pytz

arg_hour = sys.argv[1]
arg_timezone = sys.argv[2]
arg_cmd = sys.argv[3]

target_tz = pytz.timezone(arg_timezone)
target_hour = pytz.utc.localize(datetime.datetime.utcnow()).astimezone(target_tz).strftime("%H")

if target_hour == str(arg_hour):
    os.system(arg_cmd)
share|improve this answer

I recommend that you use Coordinated Universal Time (UTC), it is not effected by daylight savings. See the answers to "winter and summer time switch without a break in the timeline.". This is what it is usually best for the system time to as well.

share|improve this answer
    
I suppose I did not make my question clear enough...My issue is that I need jobs to run at 8AM local time in a region (say South Africa/Johannesburg). When daylight savings occurs, the UTC offset will end up changing to account for the new localtime and will require a manual edit to account for that. Does that make sense, or am I missing something here? –  mgray Nov 9 '09 at 19:07
    
See what Dennis said, he is right :-) –  Kyle Brandt Nov 9 '09 at 19:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.