PowerShell Automation TimeZone so confusing

This sounds like a bug to me. The time zone setting should be taking effect independent of the server time zone.

I can reproduce this. We are doing a time zone conversion incorrectly. I’ll get this fixed for 1.5.19

Thank you adam

Any Idea when version 1.5.19 included this fix will be released?

I’ll be releasing a build this week to resolve this issue and a few others. Probably in a couple of days. I can kick off a nightly build of 1.5 so you can grab it earlier if you would like. I’ll start that now.

Build 828960966 has this fix.

https://imsreleases.z19.web.core.windows.net/

thank you adam

error on description when trying to schedule script run in 1.5.19 nightly

Failed to format description: The conversion could not be completed because the supplied DateTime did not have the Kind property set correctly. For example, when the Kind property is DateTimeKind.Local, the source time zone must be TimeZoneInfo.Local. (Parameter ‘sourceTimeZone’)

script didnt run.

Can you share what your schedules.ps1 looks like?

all what am doing is to chose todays date and todays time and add just 2 minutes after to test run

New-PSUSchedule -Script “Script1.ps1” -TimeZone “America/New_York” -OneTime ‘2021-05-11T00:02:34.0000000Z’-Environment “default”

with version 1.5.18 i had to edit the script after schedule and add 4 more hours on it to get to run after 2 min like this

New-PSUSchedule -Script “Script1.ps1” -TimeZone “America/New_York” -OneTime ‘2021-05-11T04:02:34.0000000Z’-Environment “default”

in version 1.5.19 you pinged me even that didnt work and the description instead of saying Runs one time. it just says the error above no matter what time or date i chose.

Hmmm. This “fix” is broken…I’ll take another look at this tomorrow. I’m pretty certain I tried a script almost exactly like that so I might need to mess around with it more.

k thank you

Can you try to adjust this by removing the Z identifier at the end of the time.

New-PSUSchedule -Script “Script1.ps1” -TimeZone “America/New_York” -OneTime ‘2021-05-11T04:02:34.0000000’-Environment “default”

sure ill test it now

am currently on version 1.5.18 i just went to my automation screen and set a scheduled to run after 2 min from current time
my machine am logged in to is E.S.T timezone
my PSU is hosted on a server running UTC timezone

a scheduled created in schedule.ps1 script as follows

New-PSUSchedule -Script “Script1.ps1” -TimeZone “America/New_York” -OneTime ‘2021-05-11T14:02:24.0000000Z’-Environment “7.2”

i did remove the ‘Z’ from string , my Automation screen shows




which reflect current server timezone

script didnt run.

if i put the ‘Z’ back then the screen will change to




which should be correct based on my timezone

Weird. Ok. Thanks for trying. In my lab I was seeing that when I didn’t have the Z, it would fail with the error you mentioned and then if I removed it everything was correct. I’ll continue to test and adjust the time zones more to see if I can see your behavior.

by the way as extra information i did try something without using GUI
i did the code manually and put UTC timezone and put server time + 2min and it did run on time

the issue is happening up to version 1.5.18 when PSU detect the logged in user time zone and convert it to server time , you will see the time is correct but the script wont run

like for me since it detect timezone America/New-york i had to remodify the created schedule and add 4 more hours for it to run correctly.

I think I’ve realized what the issue was an hope to have resolved it. I’ve validated this latest fix with a configuration such as yours (server in UTC and client in New_York). The problem was that both UTC and non-UTC times could end up in the configuration file. The change I had made in the previous build was to convert to UTC no matter what but that’s not good enough really threw off the scheduling.

Now, it’s more intelligent about what it reads from the schedules.ps1. PSU will always write the date and time as UTC but can handle non-UTC times as well and will convert them to the specified time zone.

I’m also taking advantage of the Nodatime library rather than the built in .NET DateTime\TimeZoneInfo types because they are notoriously hard to use.

I’ve run another nightly build. If you have time, feel free to test it out. https://imsreleases.z19.web.core.windows.net/

thank you am going to test here shortly and ill let you know

Test was successful with timezone ‘America/New-York’ going to test changing timezone to sydney

That’s perfect adam its working now thank you very much for quick response

Great news! Thanks for verifying the fix. I really appreciate it.

Hi, the problem isen’t fix on 4.3.0