Current day is off - not adjusting to the timezone difference

[MadPB]

I recently updated the copy of our script from 3.6 to the latest 3.9.1 and started seeing some oddities.
As an example, we have a tag of "18:00->04:00,Saturday,Sunday"

We're in the Pacific Standard Time zone (UTC-8) and fortunately I happened to try out the new version at 4:30 PM on a Friday. That should be outside of our shutdown times, but when I ran the new version with the simulation enabled, it told me it would have shut it down because it matched on "Saturday".

Looking through the code, I saw a couple things that I think may be causing this...

In the "CheckScheduleEntry" function, line 96 takes the $currentTime value and modifies it with this:
$currentTime = $CurrentTime.AddDays((Get-Date).Day - $CurrentTime.Day)

Unfortunately, if UTC time is the next day from today, which it would be in our case anytime from 4 PM to 11:59 PM, that changes the current time variable to the next day.

There's also the section where it compares those days of the week to see if one matches, and on line 127-128 it has this:

if ($TimeRange -eq (Get-Date).DayOfWeek) {
$parsedDay = Get-Date "00:00"

But since this seems to run in Azure in UTC, that parsed day is the next day (which is what Get-Date would return) when I was testing also between 4 PM and 11:59 PM, so what should have been a Friday was actually being set as Saturday.

What ends up happening is that all of the range start/end are off by a day and strange things can happen.

What I did for now is change that line 127-128 to:

if ($TimeRange -eq ($currentTime).DayOfWeek) {
$parsedDay = Get-Date $currentTime.Date

And I commented out that part that modifies $currentTime (since it also has that Get-Date in there which will pull UTC). If I'm right and maybe that had something to do with daylight savings (? not sure about that) then at least I won't have to worry about it for now, and we don't have any tag settings that it would be a problem with anyway).

There may be better ways of accomplishing this, but it's working for me now, and this version definitely seems to fix some of the bugs we'd encountered with the old version (like a single time "18:00" not doing anything when the script ran, or sometimes machines set to Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday would turn on at points of the day when really our intention was to make sure they're always shutdown. At least, I think those things are fixed... too soon to tell since I only implemented it a couple hours ago.

[MadPB]

I noticed there was actually a discussion about UTC a few days ago and that adjustment to $currentTime was probably meant to address it? However, at least in my case, it seems to have actually triggered the issue.

I also wonder if the script is actually meant to take the current time and timezone and convert to UTC for all of the comparisons? I apologize if my comments seem dumb... :) This is my first time looking at the script after inheriting the maintenance of it from someone else, so I could be way off. I just see things where it's doing something like "$rangeStart = Get-Date $TimeRange" and I guess if $TimeRange is just an hour like "14:00" then it won't matter if it's off by a day or not, but I do wonder if there's more to it or if I'm just being dense about how it all works. :)

[tomasrudh]

Hello MadPB, you are absolutely right, my fix for time zone in 3.9.1 broke the date entry. Please give 3.9.2 a go, I think I have fixed it.

Thanks for reporting!
/Tomas

[MadPB]

That's great - I wasn't expecting such quick turnaround. I look forward to trying this out on Monday. I appreciate the effort you've put into this.

I see it looks like that UTC adjustment was moved down into the IF clause that's specific to single time-period tags (like a single 18:00) so I think that should work as expected where the other things like day-of-week tags and ranges will still work as expected.