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

  • 1
    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

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.

  • 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

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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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