Just to quote @ckrusen
2 Likes
Good morning to everyone completing this tedious task on a Sunday morning! Disappointed to report the problem where all the next run times are wrong after DST changes persists in 2023.2. Microsoft has had this problem solved for I don’t know how many years. I literally cannot remember the last time I had to worry about whether a calendar invite correctly reflected DST changes. How many more years until Epicor will figure it out?
Does anyone know if the issue persists regarding UTC? IE Schedule is set to run at 8:30pm but UTC puts it at 2:30am the next day, so if the schedule is set to daily you have to offset it (Mon-Thurs run needs to be set as Tue-Fri)
We’re on 2022.2.7 in production, and interestingly all but 1 of my schedules had to be adjusted. My 1AM daily run schedule was still set for 1AM. All others were an hour off. Super strange. They are all setup with timezones too which was supposed to be the fix, but up until this point I’ve never seen a single schedule survive the transition.
3 Likes
Assuming everyone who cares has already voted for this but just in case . . . Epicor Kinetic Ideas Portal
Not everyone! Since I previously had all of my 50 votes allocated, I could not vote for this one, but I have now, so thank you for the reminder about the idea! The vote count now stands at 128! You would think that there would have been enough votes for a while now such that a resolution would have been included in 2023.2 (if not sooner). That efferdently hasn’t been the case! (yeah, intentional, since this issue clearly causes heartburn… just threw that in there for Mr. Wonsil’s benefit!). Off to fix the system agent schedule…
1 Like
There’s a pun I can sink my (real) teeth into.
2 Likes
Same for us. Very strange…
Time is change at 3AM?, so probabaly that is why it was correct at 1AM?
1 Like
Time falls back to 1am at 2am so maybe that’s why my 1am one survived but it never has before. That’s our MRP run and I always catch flack that it changed.
@TomAlexander was yours a 1am schedule too?
1 Like
Actually it was set for 1:01AM. I had another one at 1:15AM that I did have to change.
1 Like
Out of curiosity is your 1:01AM the first agent schedule sequence? our 1AM is the first schedule in our agent. I’m grasping but it’s so weird. I know it’s always broken before this version.
1 Like
Not the first one, but has a low Schedule Number which makes me think this schedule was created many versions ago (maybe even E9)…
Hmm welp… I’ve got nothing LOL. Same though our 1AM was created back on 9.05.60X. Only reason it’s 1AM is because of this DST issue. That was in Fall it goes to midnight and still works for the current day.
1 Like
Just a thought since I once worked 3rd shift and feel like time jumped from 2am to 1am in the systems so maybe the fact it lands on the adjusted time has something to do with it?
If the times from my memory are right did it run 2 times by chance? 1 at real 1am and then again when the time fell backward?
EDIT: I see you came to this possibility further down the thread.
It did only run once and at the correct time both yesterday and today. However my 1PM schedule ran at 12PM. Super interesting. Oh well it’s still broke regardless but just an oddity.
You misspelled “feature” there… 
1 Like
Same here. BTW though, my 1:15am schedule did not actually have a task running against it. I’m wondering if it would have same behavior as the 1am if it did…
That reminds me of problems we describe as a “dilenema”. A dilemma that will end in total s#!t