Time Change - Epicor, please get your ! together

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

Wile E Coyote No GIF by Looney Tunes


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. :rofl:


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 :slight_smile:

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 :thinking:

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???

Too Late Reaction GIF by UbisoftGSA

OT: Reminds me of the Shrike form Hyperion Cantos Hyperion Cantos - Wikipedia book cover.

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.

Noda Time | Date and time API for .NET

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.


Would love to know what that is. Would you share a screenshot of one of the schedules that adjusted correctly?

Here is one of mine that did not (it jumped to 12am, which, if I hadn’t fixed it, would have meant no MRP run for Monday at all):