Got several daily schedules, and have reports that go out at specific times.
Time zone is set properly.
After time change, everything is now one hour off.
Please Stop
3 Likes
Its still not fixed even though they had said on ideas that it was fixed. I was ever so slightly optimistic when I logged in yesterday to check but alas, its just as broken as it always has been.
I was wondering about this. Those complaining (no offense) this morning didn’t mention whether or not they put the time zone in.
According to Nathan’s writeup there, there are no docs on this yet, so I don’t know how you’d know if you did it wrong anyway (except the results, of course).
1 Like
Yes I put the time zone in and its still not fixed.
I’m about to write a function that will just offset by one hour (up or down), so I can fix this in the future.
Which hopefully means they will fix it, and I will be wasting my time.
Either way, I’ll be good. 
2 Likes
Yes! Is there some Murphy’s Law corollary that covers this?
The surefire way to effect change is to have effectively mitigated every existing loophole.
Technically, you can see the next Run time in the Schedule. So if you use for example Monthly, then you can setup something to run around 1 month before next DST change and you can see, ir it works or not. SO you will have month to write the function. or complain.
1 Like
True, I had specifically made sure all our scheduled had a time zone set last Friday. I was hoping the idea --supposedly fixed-- would work and wanted to give it as much success chance as possible.
Do we have to choose only one?
up to you. i suggest the way to minimize Kevin’s effort 
1 Like
Maybe a compromise is to have the function check if the problem is fixed, and if not automatically post the complaints
sounds vaguely like automated testing 
1 Like
I thought about doing this, but… There’s no reference to an incremented static value, instead they’re incrementing a “next run date/time” value off of itself and never looking back. So applying an unattended adjustment requires assuming things in addition to the system agent’s assuming that their assumptions have always been correct throughout the history of the recurrence. Assuming things about time, that way lies madness.
The statefulness and compounding nature of errors makes this quite hard (likely not truly possible) to fix at the source without refactoring. Recurrence is actually really hard to DIY. Fortunately, it’s a well considered subject with lots of robust solutions in circulation that are easy to implement.
1 Like
Yes the entire scheduling subsystem needs to be rebuilt from the ground up imho.
1 Like
Wonder if they could tie into Windows task scheduler on the SQL DB server. The Windows one already works with time-change.
Does anybody really know what time it is???
It’s a whole thing.
1 Like
This podcast changed my opinion about date and time.
where Matt talks about his library NodaTime, which is the .NET version of the Java Time library JodaTime.
1 Like
I upgraded from 10.2.700 On-Prem to 2023.2 SaaS Public Cloud on 2/22/24.
During Go-Live weekend, I scheduled 6 new tasks using new System Agent Schedules with Time Zone. For the next three weeks the tasks ran at the correct clock time. Then, this week, I was pleasantly surprised to find that the tasks continued to run at the correct clock time (which is now Daylight Savings Time), without me having to manually adjust the schedule!.
So, there is some combination of conditions that allows the System Agent to figure out time changes.
2 Likes
