For the first time, my system agent schedule is not a disaster after dst.
15 Likes
Hell I forgot to check.
6 Likes
which version is this “fixed”.
I believe it got fixed a few months ago so at least 2024.1 but i don’t know if it got retro’d to 2023.2 or earlier.
Nope…not retro’d to 2023.2.11. Just finished my review/cleanup. Thought something was fishy when my “daily email” was an hour early…scheduled a dummy report to fire 333a daily so I know the agent is up. We’re lucky though, most of ours are most are recurring/24h entries for EDI-related stuff.
1 Like
We finally moved all of our scheduled stuff outside of Epicor.
Power Automate Flow runs an EFx that runs the thing (MRP, IWR report, etc.).
Ta da!
6 Likes
It is in .10 but you have to update TaskAgent to get the changes
5 Likes
Ah…we have EpicorICETaskAgent4.2.400 running on our app server and the times didn’t adjust automatically. OK. I just manually edited the next-run times and saved each affected task. We’re basically a Mon-Fri operation so it really didn’t cause a ruckus.
That explains it then, our 2023.2.11 automatically adjusted. Thanks Olga!
2 Likes
Ours corrected themselfs too which is odd because we were on the same version on March and it didnt correct itself… Either it knows how to go backwards, but not forwards or… we just didn’t realize it. Since we don’t really do patch updates as they come up, sometimes we will remain on a stable patch level until next major release.
CC: @jgiese.wci It looks like its a TA Update! That would make more sense.
2 Likes
I still haven’t gone back after trust issues from that time daily schedules started accumulating a daily 2 hour error from adding 24 hours + the timezone diff between server and company. Switched 'em all to UTC then, still there. Maybe if 2024.2 behaves I’ll give it a shot. Still gonna check in on DST days, but I’ve been around long enough to be surprised if nothing breaks.
1 Like
As it should be!
3 Likes
Glad to know I’m not the only one who does this.
2 Likes
I think we’re hanging at 2023.2.11 for a while…I hope. Have to balance the benefits of an upgrade versus the requirements in cost/personnel to test everything. And most of our recent problems are usually self-induced.
3 Likes
Well I lied misled - MRP is ready for this; I just haven’t pulled the trigger yet.
However, I am happy to agree that its schedule did adjust for DST.
Ironically, though, my dashboard now lies for last week because it calculates the offset based on the current UTC offset.
(MRP began for me at 11PM all 3 times IRL, despite what this dashboard looks like.)
The real System Monitor gets it right, though (11 PM all 3 days).
How does it know?
1 Like
What about sys mon in browser, what time does it show?
It’s right.
I just am curious as to how it is right. It would be nice to use the same logic or tools in my own dashboards (BAQs).
Also to whine, I had to switch users to be able to see this (I have MRP run on a service account, not my own user profile).
Back in the day, the System Monitor could “Display All Tasks” …
This is a big part of why I made my own dashboard.
Well, honestly I always had one, since it’s no fun to display all tasks and get the popups for all of them.
Me too.
Technically, if you provide date in UTC then for specific date time should be adjusted correctly, because for that date DST was used.And database just stores UTC datetime.
How do you create dashboard, do you do anything with date there? What does underlying BAQ show?
DATEADD(MI, DATEDIFF(MI, GETUTCDATE(), GETDATE()), SysTask.StartedOn)
Borrowed from: SQL Query to Convert UTC to Local Time Zone - GeeksforGeeks
Also, I never spelled this out, but I convert it because if I do not it will display as raw UTC.
For example, I am lazy and never fixed this portion of the dashboard - this is the task which runs at 11 PM in this time zone. It displays as 4 AM.
