Why is the Network job running one hour later than scheduled?
The reason is due to Daylight Saving Time (DST). Prior to version 18R1.2, Network had no awareness of time changes and did not adjust the schedule accordingly. All processes were run in terms of Standard Time. The servers that power the application are based in the Pacific Time zone. During the time of year when Standard Time is in effect (typically from the first Sunday in November to the second Sunday in March) the schedule and execution times were in sync. Between the second Sunday in March to the first Sunday in November, while Daylight Saving Time is in effect, the schedule and execution times were one hour off.
After version 18R1.2, Network adjusts for Daylight Saving Time for schedules. Now, when administrators or data managers schedule new subscriptions of any kind, the scheduled time will reflect their current time zone. If they are in an area with Daylight Saving Time, the time shown in the Network UI for the configured schedule will adjust and reflect DST. This also applies if a new schedule is added to an existing subscription.
Existing schedules in subscriptions that were created prior to version 18R1.2 do not adjust to daylight saving time unless the existing schedule is updated in any way and then saved; the schedule will update to adjust for DST from that point onwards.