我們用實際例子來驗證一下：
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的時間和新時區的組合體了。