Enable JobScheduler to schedule jobs/chains with respect to TimeZones

JobScheduler: Time Zone consideration (First Draft).

Abstract:
JS must to be able to submit/schedule jobs to
servers in different time zones (TZ), and execute them in their own TZ.
That way, one must be able to provide for time zone changes in other
TZ's.
it should be also possible to define all run-times in UTC and JS has to adjust the
<run-time> to the local time of the acutal instance of JS. That would enable a general
scheduling on different time-zones based on an unique understanding of time.

Licencing:
"Time zone consideration" could be a component of the enterprise-scheduling-suite and therefore
available in a commercial licence only.

Affected Modules/Components/Systems:
JS binary, JSObjectEditor, Managed-Job GUI, Operations-GUI, Deployment-Job, JSGrantServer...

General picture:
Every <run_time>-tag must have a <time_zone>-Tag (IV) to meet this requirement.
if there is no <run-time>-tag then the local time of the actual server is assumed,
tz is taken from customizing (I).
JS has (I) to know the name of the TZ of its own instance and has to have the
(II) knowledge about
the handling of TZ-dependent scheduling. Due to the fact, that there is no standard or
naming convention of tz's out there a tz-customizing-table for JS is needed (V) and must
be maintained (VI) e.g. by the JSObjectEditor.
For a better internal handling of scheduling-times it could be a good approach to consider
all run-times internaly in UTC (III) and report the run-times on the <calender> even in UTC
or a given TZ (VII).

Details:
(I) There must be a <time_zone_section> in the scheduler.xml (configuration-file). this section
contains the tags listed as a structure below:

...
<time_zone.section>
<time_zone.local name="CET" />
<time_zone.map>
<time_zone.map.entry name="PST" descr="Pacific Standard Time" time_diff="-08:00" dst_start=MMDDHHmm dst_end=MMDDHHmm dst_diff="+1"" />
<time_zone.map.entry name="MST" descr="Mountain Standard Time" time_diff="-07:00" dst_start=MMDDHHmm dst_end=MMDDHHmm dst_diff="+1"" />
<time_zone.map.entry name="CST" descr="Central Standard Time" time_diff="-06:00" dst_start=MMDDHHmm dst_end=MMDDHHmm dst_diff="+1"" />
<time_zone.map.entry name="EST" descr="Eastern Standard Time" time_diff="-05:00" dst_start=MMDDHHmm dst_end=MMDDHHmm dst_diff="+1"" />
<time_zone.map.entry name="UTC" descr="Universal time coordinates" time_diff="0" />
<time_zone.map.entry name="CET" descr="Central ..." time_diff="+01:00" dst_start=MMDDHHmm dst_end=MMDDHHmm dst_diff="+1" />
<time_zone.map.entry name="CNST" descr="China Standard Time" time_diff="-08:00" dst_start=MMDDHHmm dst_end=MMDDHHmm dst_diff="+1"" />
...
</time_zone.map>
</time_zone.section>
...
Atributes used:
time_diff = the offset as hh[:mm] used to add to UTC to get local time.
dst_start = the date+time on which the daylight-saving-time begins
dst_end = the date+time on which the daylight-saving-time ends

Rules:
a) the time_zone.section is mandatory
b) the time_zone.local is mandatory
c) the time_zone.map is optional, but must be defined if time_zones are used in scheduling

All names listed in a time_zone.map.entry are allowed as a name for a time-zone.

(II) JS must calculate differences between time-zones using the time_diff attribute of the source- and
the target-time-zone.

(III) no matter which tz is defined in a run-time, JS could use UTC for scheduling internaly.

(IV) the <run_time>-tag must be extended by an extra child:

...
<run_time ...>
<time_zone name="UTC" ... />
...
</run_time>
...
for shorter writing the attribute "time_zone" should be possible, too.
All Childs of <run_time> has to respect to time_zone definition (e.g. date).
if a <schedule> or <ultimo> is defined for the run_time the time_zone definition is taken into account accordingly.
if there is no <time_zone>-tag specified the value of the <time_zone.local> of the scheduler.xml
is used.

(V) this is the <time_zone.map> as shown in (I).

(VI) JSObjectEdtior and "Manged Job GUI" must have the capability to maintain the <time_zone.section> and the <time_zone>-tab
for a <run_time>.
All Input has to be valiated against the time_zone.map.
The time_zone.section must be implemented as a class.
The OperationsGUI will show the run_times according the value received from the JS.

(VII) the calendar-tag must be extended by an additional attibute time_zone="name" which the
time-zone specifies for which all <run_times> have to be adjusted.

(VIII) The answer of the <show_job> must include the attribute "time_zone".

(IX) The answer of the <state>-command must include the attribute "time_zone".

more Details:
(X) if a Job is deployed to a remote-instance, the time_zone has temporarily set to utc and the
run_time has to be recalculated. This has to be done by the deployment-job which has to read the
time_zone.map .

(XI) the <start_job>-tag must be extended by the time_zone-tag. If no time-zone given in start_job the local
time-zone of the JS instance is used.

(XII) a nice implementation/interpretation of the time_zone scheduling could be the inverse interpretation of a tz-definition.
e.g. a job must run on a local server if the time, given for another time-zone, is reached. this is helpful
for ftp-jobs with which files are pulled from a remote-server located in another time-zone. Instead of writing 07:00 CET
for a job which is getting data from a server located in the PST-Zone (and one must have always in mind, that the data must be ready
at 23:00 local server time) it should be possible to write 23:00 PST and the job is scheduled local on the next day at
local time 07:00.

Code:
just an simple example on how to get the time for a given time-zone, based on local time:

// formatter
DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL);
Date now = new Date(); // local date
TimeZone timezone = TimeZone.getTimeZone("Japan"); // instanciate timezone
df.setTimeZone(timezone); // register on formatter
System.out.println("Japan time is:"+df.format(now)); // recalculate

Further readings:
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm