On Sun, 11 Aug 2013 17:41:04 +0800, Timothy Sipples wrote:
>I can think of a couple more possibilities:
>
>1. A job scheduler such as IBM Operations Manager for z/VM (IBM program
>number 5697-J10), CA VM:Schedule, etc. might handle this requested use case
>directly.
>
>2. A job scheduler -- on z/OS notably -- could start a job via RSCS or FTPS
>in z/VM. (This is a variation on the Linux idea.)
>
Of these, how many can handle more timezones than "GMT" and "LOCAL"?
(After all, the topic is "Multiple timezones" and the OP's requirement is
clear.)
>These two possibilities depend somewhat on how smart the scheduler is about
>periodic shifts in local time, e.g. daylight savings time. Many job
>schedulers are pretty smart. I'm generally in favor of scheduling jobs in
>one logical place if possible and absent a compelling reason otherwise.
>
>Note that the local time changes rather often in the world, hence the
>previous paragraph and its "once and once well" view. Operating system
>release X.Y.Z may not have a current understanding of the correct local
>time in a particular geography if enough time passes.
>
Indeed, the data base must be updated in a timely, hopefully
nondisruptive fashion. For a Horrid Example, Independent Samoa
advanced its clocks by 24 hours on December 1, 2012. So:
512 $ TZ=UTC0 date
Sun Aug 11 15:13:36 UTC 2013
513 $ ssh 192.168.0.5 "uname; TZ=Pacific/Apia date"
Linux
Mon Aug 12 04:13:43 WST 2013
Ubuntu Linux had it right, even in anticipation of the change
(admittedly, the system has been restarted since the change,
so I can't vouch for "nondisruptive"), but:
514 $ uname; TZ=Pacific/Apia date
Darwin
Sun Aug 11 04:14:16 WST 2013
OS X (above; admittedly an out-of-support release), Solaris,
and various other Linuxen still haven't got it right 16 months
after the fact.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
