If a customer creates a new PA Data Collection Job and sets the time to be executed and the instance time zone is currently on daylight-savings/summer time, then this job may execute on a different time than configured.
This issue has to do with the Schedule table [ sys_trigger ] that is generated and will execute the job at the proper time, the record has two fields: Run Time [run_time] and Next Action [next_action]
The "run time" field is a glide_time field, it does not account for the summertime savings change, therefore, the time the job will be executed will be different than expected. This normally occurs on the first time the job is executed after the PA Job is created or updated because then the sys_trigger records get recreated.
The "next action" field is a glide_date_time field, which supports the daylight-savings/summer time, and it is used to generate the "run time" of the sys_trigger record that will execute the data collection on the next date. This will set the time of the execution properly and the following executions will be done at the correct time.
Steps to Reproduce
- On an affected instance, set the instance time zone to British time zone or the European Central
- Create a new PA Job to execute a data collection at 00:00:00 and the frequency should be Daily to proper reproduction
- If this change is done during the summer time/daylight savings, observe that the PA Job will not execute at midnight of the next day, but it will be executed on at 23:00:00 of the current day of the change
- The consequent executions will be done at midnight
After carefully considering the severity and frequency of this problem and the risk of attempting a fix, it has been decided to not address this issue in any current or future releases. We do not make these decisions lightly, and we apologize for any inconvenience. If you have any questions regarding this problem, contact ServiceNow Technical Support.
However here are two workarounds to avoid any problems of collecting the PA Scores on the wrong date. The advice is to:
- Avoid executing the PA Data Collection before 1 AM if your instance timezone does have the yearly daylight-savings/summer time;
- In case you change a PA Data Collection job during the summer time, find the correspondent record on sys_trigger table and adjust the "run_time" field, adding one hour to the time registered there.
Related Problem: PRB660662