我们用实际例子来验证一下：
Test1:
1.首先看一下默认系统时区:
oracle@fmw11g.vm.oracle.com $ date
Sat Nov 19 03:50:10 GMT 2016 <'TJ1',
job_type => 'STORED_PROCEDURE',
job_action => 'JOB_PRO_TEST1',
start_date => sysdate + 1/24, <<1hour 之后开始运行
enabled => true,
auto_drop => true 
);
end;
/ 
3.check job的运行状态
select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';
MAOB

TJ1 JOB_PRO_TEST1

11/19/2016 4:51:26.000000 AM +00:00

SCHEDULED
<< 03:51提交的，计划在GMT的上午4:51开始运行 
Test2:
1.检查一下当前时间
oracle@fmw11g.vm.oracle.com $ date
Sat Nov 19 03:54:30 GMT 2016 << alter SESSION set time_zone='+08:00'; <<<
begin
dbms_scheduler.create_job(
job_name=>'TJ2',
job_type => 'STORED_PROCEDURE',
job_action => 'JOB_PRO_TEST1',
start_date => sysdate + 1/24, <<仍然1hour 之后开始运行
enabled => true,
auto_drop => true
);
end;
/
3.check job的运行状态
select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';
MAOB

TJ2

JOB_PRO_TEST1

11/19/2016 4:54:34.000000 AM +08:00

RUNNING 
<<刚刚提交的job，居然计划在中国时区的4:54:34+08:00运行，因为系统当前时间是03:54:30 GMT，对应中国时区的11:54:30+08:00,所以
显然是之前的时间，所以等于过期了，于是scheduler发现需要立即运行，也就处于RUNNING状态了
Test3:
1.检查一下当前时间并通过操作系统设置时区
oracle@fmw11g.vm.oracle.com $ date
Sat Nov 19 04:02:42 GMT 2016 < begin
dbms_scheduler.create_job(
job_name=>'TJ3',
job_type => 'STORED_PROCEDURE',
job_action => 'JOB_PRO_TEST1',
start_date => sysdate + 1/24, <<仍然1hour 之后开始运行
enabled => true,
auto_drop => true
);
end;
/ 
3.check job的运行状态
select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';
MAOB

TJ3

JOB_PRO_TEST1

11/19/2016 1:02:57.000000 PM +08:00

SCHEDULED
新job计划时间是北京时间1:02:57，这个正式符合要求的
综上所述，正常在操作系统层面调整时区是不会影响job时间的，但是对于通过alter sessoin 调整时区
需要谨慎，因为server process还是fork起来时候的时间(GMT)我们突然把session的时区给修改了，但是时间
是不会变的，所以start_date就是变成GMT的时间和新时区的组合体了。