This is a complex topic but I’ll try to relate my understanding of it. It’s not technically a bug, but it might not be the behavior anyone would expect or want…but I don’t see an easy way around it with worldwide scheduling options.
When we create a schedule in Patch Policy set to use “client local time”, the WebUI engine has to calculate that policy for the earliest possible time zone in the world, which is UTC+1400. The main problem is that if we are already “too late” to meet a scheduled time, Patch Policy will not create an action for the schedule that’s already late - it waits for the next occurrence to send an action. And if you’ve set the policy to “Start downloads 12 hours before the scheduled time”, the actions have to be created 12 hours even earlier – or it’s already too late to meet the first schedule, and the engine waits for the next schedule time.
What does this mean in practice? That you can’t create a schedule for today, or in most cases for tomorrow, and expect to see those actions – at least if you schedule with “Client Local Time”.
Here’s an example. Today is Wednesday October 13 at 2pm (14:00) in US Central Time. I want to create a policy to run “Every Thursday of the month at 6pm (18:00) in Client Local Time, and precache the patches 12 hours before the actions execute”.
To send actions that run on Thursday at 1800 Client Local Time with 12 hours of precaching, the automation engine determines that the first time Thursday 1800 occurs in the earliest time zone on earth, UTC+1400 will occur 14 hours before Thursday 1800 UTC time - on Thursday 04:00 UTC time. The action has to be issued twelve hours before that to allow for the precaching, so the action must be issued on Wednesday at 16:00 UTC time.
Since today is Wednesday Oct 13, at 14:00 CST, my current UTC time is Wednesday 19:00 UTC. It’s too late to send the action for this cycle, it would have been created three hours ago. Since it’s too late for this schedule, the engine is going to wait until next week and create an action on Wednesday, Oct 20 at 16:00 UTC (11:00 CST) to start precaching and begin executing for next week’s “Thursday 18:00 Client Local Time”
What if we want the action to run today, on a machine in US Central Time, using Client Local Time? Too late, if we’re going to schedule using “Client Local Time”. Even if we drop 12-hour precaching, then my current Wednesday 14:00 CST equates to Wednesday 19:00 UTC, or Thursday 10/14 09:00 in UTC+1400. So right now, the earliest “Client Local Time” action that I can issue for Patch Policy is sometime later than “Thursday 10/14 09:00 Client Local Time”.
Unfortunately the “simplest” way around this in Patch Policy right now is to schedule using “UTC Time Zone” rather than “Client Local Time”. That way the automation engine can schedule based on an absolute time, rather than that “earliest time zone possible” of UTC+1400.
From a feature/development standpoint, the only way I could see getting around it is a button on the schedule config for something like “Issue actions immediately if the schedule has already passed”. I’ve lobbied for that, and I suggest adding an Idea for that (since customer-driven Ideas tend to get higher priority).
One other workaround I might suggest, is to combine Patch Policy with the Maintenance Window Wizard. We can configure the Patch Policy schedule to respect the “Run in a maintenance window” setting, configure the Patch Policy schedule to run in UTC time, and use the Maintenance Window Wizard to lock/unlock the machines when you really want the patches to execute (using client local time).
The only other option I can think of is to just be sure all the patch policy schedules are set up far enough in advance that you don’t have to worry about the “Too late to run the policy today or tomorrow” thing. If, today, I set up a schedule to run on Friday, those actions will get issued tomorrow and run as scheduled. It’s only today & tomorrow that are a problem.
I don’t expect anyone to be excited with this answer, but hopefully this helps you understand why it’s a tricky problem with no real good solutions.