Slashdot Mirror


Managing Batch Jobs for Several Time Zones?

sporty asks: "I have one machine, a unix box, that serves many time zones at once. Because of this, everything is stored in GMT. Even the system clock is set relative to GMT. The problem is determining when midnite is. I need to run certain jobs, via cron or similar, so that something runs at midnite in that timezone. Anyone have this situation before?"

8 of 44 comments (clear)

  1. GMT offsets are your friend. by PeteyG · · Score: 2, Informative

    -Find out what the GMT offset for each time zone is.
    -Use that to figure out what GMT time is midnight for each time zone.
    -Make a cron job for each time zone to run when it is midnight in that time zone.

    Unless there is something about the question I don't understand...?

    --
    no thanks
    1. Re:GMT offsets are your friend. by Malcolm+MacArthur · · Score: 2, Informative

      Because the clock offsets change, and change at different times for different timezones... I presume you want to avoid going through a list of timezones once a week and adjusting the jobs :(

    2. Re:GMT offsets are your friend. by sporty · · Score: 2, Informative

      Nope, I'm dealing with worldwide timezones. If it were simple as puttin in the crontab, run at midnite GMT or midnite, EDT5EST (I've seen that somewhere), that'd pwn. Problem is, cron doesn't support that. Well.. not yet if I don't find an easier solution than "fixing' cron in c.

      --

      -
      ping -f 255.255.255.255 # if only

  2. Please, geeks of the world by Anonymous+Cowdog · · Score: 5, Informative

    Don't know if this advice applies to this guy or not, because he might truly have a need to run at exactly midnight. But please, run your cron jobs at randomly chosen times, instead of exactly on the hour. That way we can spread the load (machine and network) better. Thank you, have a nice day.

  3. Re:Not enough information by sporty · · Score: 2, Informative

    Right now, the time zone I'm in respects daylight savings. Midnite is gonna shift in the fall, as well as in april. Places like england or or barbados celebrate it at different times or not at all.

    Writing a job managing job on top of a job managing job (at on cron) could get messy. Especially so when day light savings hits for various places.

    --

    -
    ping -f 255.255.255.255 # if only

  4. TZ is your friend by sysadmn · · Score: 4, Informative
    Fun Facts:
    • The TZ environment variable is used to determine how to interpret times.
    • Most shells allow you to set environment variables for a single command by specifying them on the command line

    i.e.
    $ TZ=EST5EDT at 12 am
    ...
    $ TZ=PST8PDT at 12 am
    ...
    $ at -l
    1058932800.a Wed Jul 23 00:00:00 2003
    1058943600.a Wed Jul 23 03:00:00 2003
    --
    Envy my 5 digit Slashdot User ID!
  5. DateTime.pm is your friend by Space_Nerd · · Score: 4, Informative

    Check it out, it converts between timezones automagically, respects daylight savings, and all of the fun stuff.

    It's really a lifesaver, here is a link DateTime.pm

    --
    Everybody has a purpose in life, maybe mine is to lurk in slashdot.
  6. correction... by Xtifr · · Score: 3, Informative
    I just noticed that there's a bug in that approach. On days when the time changes, you might end up running the job twice or not at all.

    However, there's another simple solution. Again, based on the fact that there's really only two times that can be local midnight. Simply run a script like this at the earlier of the two times:
    if [ $(TZ=$1 date +%H) = 23 ]; then # it's 11pm in timezone $1
    sleep 1h # wait till midnight
    # (on some systems, you might need "sleep 3600")
    fi
    run_my_midnight_task
    Note that hacking cron to respect timezones will result in the same bug as my earlier approach. So, this approach is really the cleanest I can see.