DST questions, part duex

Question

Oracle 11.20.1.0 SE-One
Oracle Linux 5.6 x86-64
Cut to the chase. Most of our scheduler jobs are defined such that start_date, last_start_date, and next_run_date all specify the timezone with a fixed offset. As a result, the first execution after the DST time change, they ran one hour early, but then computation for the next run corrected and they fell back to running at the scheduled time.
Well, almost.
We have two application schemas that own scheduler jobs.
The jobs in one schema behaved as above.
But all of the jobs in the other schema continue to run one hour early.
the above can be observed in the output from this query:
select
     instance_name
,     systimestamp
from
     v$instance;
select
     owner
,     job_name
,     log_date
,     status
from
     dba_scheduler_job_log
here   log_date > sysdate - 10
  and   owner not in ('EXFSYS',
                      'ORACLE_OCM',
                      'PERFSTAT',
                      'SYS'
order by
     owner
,     job_name
,     log_date
;Very easy to just go down the LOG_DATE column and see the time change.
So my first of two questions is - can anyone explain the above behavior, especially the inconsistency in the jobs of one schema 'healing' themselves after the first run after the time change, but the jobs of another schema continuing to run an hour early.
I don't know if it bears on it or not, but most of the jobs (both schemas) are scheduled with a home-grown function for 'frequency' that uses a decimal representation of time (ie: WEEKLY(.4583,'SATURDAY') )
And a second question - what are the things that influence the timezone representation in the START_DATE when defining a new job? Our programmer creates/maintains the jobs using SQL Navigator, and there is no provision in the GUI there for specifying either a specific time zone or the method (offset vs. name) of representing a timezone. I've read that there are some client-side influences but haven't pieced that together just yet.

Answer 1

spajdy wrote:
Job JOB_PEOPLESOFT_EXTRA, repeat_interval is in CALENDAR, syntax start_date=09-NOV-12 09.45.00.000000 AM -06:00 time zone is specified by absolute offset -6:00. So this job can't follow DST because as ORACLE doc say:
The calendaring syntax does not allow you to specify a time zone. Instead the Scheduler retrieves the time zone from the start_date argument. If jobs must follow daylight savings adjustments you must make sure that you specify a region name for the time zone of the start_date. For example specifying the start_date time zone as 'US/Eastern' in New York will make sure that daylight saving adjustments are automatically applied. If instead the time zone of the start_date is set to an absolute offset, such as '-5:00', daylight savings adjustments are not followed and your job execution will be off by an hour half of the year.
Yes, I'm with you so far.
Job EVENT_TRANSFER, repeat_interval is in PL/SQL syntax, start_date=05-NOV-12 10.30.00.000000 AM -05:00. Because repeat_internal is in PL/SQL = function MON_TO_FRI then timezone for next_run_date is defined by this function. And this function use SYSDATE.
And this is where I'm missing something. I don't see how the timezone is defined in the function whose code I provided. SYSDATE doesn't carry TZ info.
And anticipating the next question ...
SQL> DECLARE
  2   x VARCHAR2(100);
  3  BEGIN
  4    dbms_scheduler.get_scheduler_attribute('DEFAULT_TIMEZONE', x);
  5    dbms_output.put_line('DTZ: ' || x);
  6  END;
  7  /
PL/SQL procedure successfully completed.
SQL> set serveroutput on
SQL> /
DTZ: CST6CDT
PL/SQL procedure successfully completed.
A we can see SYSTIMESTAMP has now timezone -06:00. In DST it is hour shifted =-5:00.
So what's conclusion:
1/ when you are using PL/SQL syntax for repeat_interval then time zone is defined by used expression. In your case by function MON_TO_FRI. This function is based on SYSDATE and this function change timezone twice a year (DST start and end).And that's what I'm failing to see -- HOW it is defined by the ps/sql function.
2/ when you are using CANLENDAR syntax for repeat_interval and you want job to follow DST changes correctly you must specify start_date with timezone in region/city.
3/ if you want to correct job JOB_PEOPLESOFT_EXTRA disable it, set start_date with correct timezone definition and then enable job Yes. Actually, my testing has shown no reason to disable the job first. I've seen that if it simply unset start date (dbms_scheduler.set_attribute_null ('ESTEVENS.EDST_TEST_3','START_DATE');), the TZ for START_DATE gets set to the DEFAULT_TIME_ZONE (see above) AND .... the TZ spec in NEXT_RUN_TIME gets reset as well. If REPEAT_INTERVAL is specified as an interval, NEXT_RUN_TIME gets adjusted to match the current time, but if it is specified as an absolute (BYDAY, BYHOUR, etc.) only the TZ info of NEXT_RUN_TIME will change.
>
dbms_scheduler.stime return 12-NOV-12 11.45.24.658242000 AM CST6CDT so I hope that CST6CDT is correct timezone of your DB. You profile says that you are located in TN - USA and UTC-6 is for Tennessee (middle and western)- Memphis dst.I've got the fix ready to implement and fully tested, and in addition to fixing the TZ info itself, we are going to replace the home-grown functions with standard calendar syntax. At this point I'm just trying to fill in the last bits of my understanding. Purely academic now.