What is the time zone of the management unit (Workforce Management / Configuration / Management Units / ...)?
What is the time zone of an agent who sees the schedule being out an hour more than it should be?
What is the time zone of an agent who sees the schedule correctly?
When an administrator/supervisor looks at the schedule for the management unit in the same time zone as the agent is in (you can use the time zone picker in the schedule editor), are the times as expected?

If there is a disparity in two different machines running the same code that does the same UTC to local time conversions in the same time zone, then I would lean toward a difference with the two machines (e.g., system preferences, time zone selection, OS patch level).

The only known case of 'walking' behavior of schedules is when the management unit's time zone and the agent's time zone have a disparity in DST observation/handling. E.g., one honors DST and one doesn't or one has a 30m bias and another has a 60m bias. For that case after DST transitions the 'walking' behavior will be whatever the DST bias (e.g., 60m, 30m, etc. leap forward / fall back). For the cases the walking behavior is not desired, then the work plans must be adjusted to account for the desired behavior (business versus agent decision).

DST transition for AU was 07-Oct so if you are just recently seeing an issue, then this may not have anything to do with DST observations across AU. Just wanted to show some finer points on DST just in case.

What is the time zone of the management unit (Workforce Management / Configuration / Management Units / ...)?
What is the time zone of an agent who sees the schedule being out an hour more than it should be?
What is the time zone of an agent who sees the schedule correctly?
When an administrator/supervisor looks at the schedule for the management unit in the same time zone as the agent is in (you can use the time zone picker in the schedule editor), are the times as expected?

If there is a disparity in two different machines running the same code that does the same UTC to local time conversions in the same time zone, then I would lean toward a difference with the two machines (e.g., system preferences, time zone selection, OS patch level).

The only known case of 'walking' behavior of schedules is when the management unit's time zone and the agent's time zone have a disparity in DST observation/handling. E.g., one honors DST and one doesn't or one has a 30m bias and another has a 60m bias. For that case after DST transitions the 'walking' behavior will be whatever the DST bias (e.g., 60m, 30m, etc. leap forward / fall back). For the cases the walking behavior is not desired, then the work plans must be adjusted to account for the desired behavior (business versus agent decision).

DST transition for AU was 07-Oct so if you are just recently seeing an issue, then this may not have anything to do with DST observations across AU. Just wanted to show some finer points on DST just in case.

Another thing to check is, on the machine where the PureCloud time is shown incorrectly, if the time shown in the bottom right of the following page is correct...

https://jsfiddle.net/tjzo124x/136/

What is the time zone of the management unit (Workforce Management / Configuration / Management Units / ...)?
What is the time zone of an agent who sees the schedule being out an hour more than it should be?
What is the time zone of an agent who sees the schedule correctly?
When an administrator/supervisor looks at the schedule for the management unit in the same time zone as the agent is in (you can use the time zone picker in the schedule editor), are the times as expected?

If there is a disparity in two different machines running the same code that does the same UTC to local time conversions in the same time zone, then I would lean toward a difference with the two machines (e.g., system preferences, time zone selection, OS patch level).

The only known case of 'walking' behavior of schedules is when the management unit's time zone and the agent's time zone have a disparity in DST observation/handling. E.g., one honors DST and one doesn't or one has a 30m bias and another has a 60m bias. For that case after DST transitions the 'walking' behavior will be whatever the DST bias (e.g., 60m, 30m, etc. leap forward / fall back). For the cases the walking behavior is not desired, then the work plans must be adjusted to account for the desired behavior (business versus agent decision).

DST transition for AU was 07-Oct so if you are just recently seeing an issue, then this may not have anything to do with DST observations across AU. Just wanted to show some finer points on DST just in case.

Another thing to check is, on the machine where the PureCloud time is shown incorrectly, if the time shown in the bottom right of the following page is correct...

https://jsfiddle.net/tjzo124x/136/

What is the time zone of the management unit (Workforce Management / Configuration / Management Units / ...)?
What is the time zone of an agent who sees the schedule being out an hour more than it should be?
What is the time zone of an agent who sees the schedule correctly?
When an administrator/supervisor looks at the schedule for the management unit in the same time zone as the agent is in (you can use the time zone picker in the schedule editor), are the times as expected?

If there is a disparity in two different machines running the same code that does the same UTC to local time conversions in the same time zone, then I would lean toward a difference with the two machines (e.g., system preferences, time zone selection, OS patch level).

The only known case of 'walking' behavior of schedules is when the management unit's time zone and the agent's time zone have a disparity in DST observation/handling. E.g., one honors DST and one doesn't or one has a 30m bias and another has a 60m bias. For that case after DST transitions the 'walking' behavior will be whatever the DST bias (e.g., 60m, 30m, etc. leap forward / fall back). For the cases the walking behavior is not desired, then the work plans must be adjusted to account for the desired behavior (business versus agent decision).

DST transition for AU was 07-Oct so if you are just recently seeing an issue, then this may not have anything to do with DST observations across AU. Just wanted to show some finer points on DST just in case.

Another thing to check is, on the machine where the PureCloud time is shown incorrectly, if the time shown in the bottom right of the following page is correct...

https://jsfiddle.net/tjzo124x/136/

What is the time zone of the management unit (Workforce Management / Configuration / Management Units / ...)?
What is the time zone of an agent who sees the schedule being out an hour more than it should be?
What is the time zone of an agent who sees the schedule correctly?
When an administrator/supervisor looks at the schedule for the management unit in the same time zone as the agent is in (you can use the time zone picker in the schedule editor), are the times as expected?

If there is a disparity in two different machines running the same code that does the same UTC to local time conversions in the same time zone, then I would lean toward a difference with the two machines (e.g., system preferences, time zone selection, OS patch level).

The only known case of 'walking' behavior of schedules is when the management unit's time zone and the agent's time zone have a disparity in DST observation/handling. E.g., one honors DST and one doesn't or one has a 30m bias and another has a 60m bias. For that case after DST transitions the 'walking' behavior will be whatever the DST bias (e.g., 60m, 30m, etc. leap forward / fall back). For the cases the walking behavior is not desired, then the work plans must be adjusted to account for the desired behavior (business versus agent decision).

DST transition for AU was 07-Oct so if you are just recently seeing an issue, then this may not have anything to do with DST observations across AU. Just wanted to show some finer points on DST just in case.