Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

From a server hosted in Poland (UTC +01:00), is there a way I can consistently have a crontab entry run at 9am New York time (UTC -05:00)?

For me this wasn't trivial since the daylight saving time ended last Sunday in Poland, so jobs that I have scheduled to run at 15:00 their local time most of the year are late this week by an hour from the point of view of US stock exchanges.

I remember Congress' decision a few years ago to extend DST, which put things out of sync for a few weeks per year.

One workaround I am not even sure would work (which I prefer to avoid anyhow) is that when I have a task:

0 14 * * * something

I fetch NY's time TZ=":US/Eastern" date +%s and compare using bash arithmetic whether I should sleep 3600 or not before running something

share|improve this question
Hmmm, you could pass the TZ environment variable to cron in its init.d script (TZ=':America/New_York') to have all your cron jobs run in New York time. BTW: New York is currently on DST, and is thus UTC-0400. –  derobert Nov 1 '12 at 16:02
No; I don't want all, and according to some other posts, TZ doesn't necessarily affect crontab (in Ubuntu which I use it doesn't), unlike for date eg. TZ=":US/Eastern" date +%Y%m%d –  Marcos Nov 1 '12 at 16:04
Minor update. en.wikipedia.org/wiki/Tz_database implies that since the DST rules for each zone are published into the TZ database, any up-to-date UNIX server should already have bundled knowledge of the wall clock time anywhere else in the world without having to consult over the network. –  Marcos Nov 1 '12 at 17:30
add comment

2 Answers

If its only one job, you can use a kluge like this:

# MM HH        DM MN DW   CMD
  0  *         *  *  *    TZ=':America/New_York'; if [ `date +\%H` -eq 9 ]; then actual-command-here; fi

I think you can set the environment variable like that in a crontab, if not just put the whole thing in a sh -c or a shell script...

I have a cron job that I need to run every other week which I use a similar kluge for.

share|improve this answer
Thanks for the kluge; 9am was only a simplified example, in reality I have tasks sprinkled all over the clock and calendar. Developing on your idea, rather than stuffing my much longer, nastier crontab line into an if block, I could merely precede my commands with: ` [ $[$(date +%H) - $(TZ=":US/Eastern" date +%H)] == 5 ] && sleep 3600; w` where w is what I want to run at the right time –  Marcos Nov 1 '12 at 16:19
sleep 3600 is only if you can only ever come in one hour early. What about when DST starts (Spring, instead of fall?) –  derobert Nov 1 '12 at 17:33
The idea is that for most of the year, a 1-hour wait will not be in effect. Only during the few weeks of a 5-hour difference (whether spring or fall), rather than the typical 6, will sleep 3600 be executed. –  Marcos Nov 1 '12 at 17:43
Um, the opposite of what I last wrote. –  Marcos Nov 1 '12 at 21:53
add comment
up vote 1 down vote accepted

Okay, since altering the TZ env for date does seem to call up the correct current time in Ubuntu, this is at least a workaround (the one I was trying not to rely on):


0 14 * * 1-5  [ $[10#$(date +\%H) - 10#$(TZ=":US/Eastern" date +\%H)] == 5 ] || sleep 3600; w;df

So this aims to run w;df at 9am ET Mon-Fri. Instead of hour 15 I put in 14 with the possibility of sleeping one hour (3600 seconds) before running further commands.

share|improve this answer
I don't like that 1. this isn't a host-timezone-indifferent solution, and 2. assumes the difference will never be greater than six hours, i.e., that DST in Poland will always end first and start last. –  Marcos Nov 1 '12 at 17:52
In some cases got /bin/bash: 15 - 09: value too great for base (error token is "09") due to subtle problem of bash treatment of numbers beginning with 0 as octal. Fixed by preceding 10# to numbers. –  Marcos Nov 5 '12 at 15:27
add comment

Your Answer


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.