Calvin, I have had to do this since Epicor 9, is there any setting in the system to accommodate DST? I know in site maintenance there is something for time stamps that takes DST into consideration.
@utaylor UGH!! I forgot about this. I had so many issues in the spring and my scheduled tasks still get a day off once in a while. I never noticed an issue in E9.
Yeah 
We stopped running anything on Sunday nights anyway–that’s when IT does updates and reboots servers, etc.
My favorite thing I discovered is that the System Agent looks at time locally, but dates in GMT/UTC.
So, if I tell MRP to run at 8PM every night except Sunday here on the East Coast (GMT -5), it runs Sunday-Friday at 8PM (local). I had to uncheck Monday for it to run Monday-Saturday.
Think about that.
But for a process that runs at 5AM, I’m fine saying the actual days.
I have found many issues with the scehduled tasks in E10. They have never been right since daylight savings in spring; that is when all my issues started. We run some things on a monthly scheduled and it will run for a month or 2 fine then it changes the start date to the day before. Very frustrating. And with DST…my schedules all reverted an hour…again frustrating. Just because the time changed doesn’t mean I don’t want the schedule to change…I still want it to run at 11pm not 10pm now.
I actually spent the time making a BPM that would automatically detect DST, and adjust next run time accordingly. But I only did it as an exercise, and never really implemented it. Here it is:
1 Like
i just spoke with epicor again…of course no resolution. they have a problem case logged but no fix date.
3 Likes
I attempted to report this a few years ago and they asked me to reproduce it. I told Epicor I would need a time machine to reproduce or we would have to wait until time changes back to observe it happening. They told me since they cannot reproduce it on their end there is nothing to report. I ended up creating a script I have to run twice a year. It really seems that for those of us that rely on Epicor’s task scheduler to run automated tasks, it is not asking much for them to modify this behavior to run using the server time, not GMT.
2 Likes
What’s the case #? Maybe if we got a thousand or so of us to open a call against it we could get the fix scheduled?
I only had to fix the microwave and stove clocks in my house manually. Thought I got off easy until I went to work and found out MRP was running an hour earlier than expected…
4 Likes
In a effort to not have our schedules change when daylight savings time happens I set the timezone for our companies in company maint. This morning I came in and setting our company in the UK to the proper timezone, caused clock in times to be 5hrs ahead of when they actually clocked. Wouldn’t recommend setting this field, no idea why it would have done that to clocked time. The field help for the field is not very helpful either.
I believe that setting has to take into account where the App Server is. Most people that are On Premises, most likely have the server in their HQ/Main location. So there’s no diff between the local users and the app server.
So this setting doesn’t take into account the local time on their computer at all? Seems like the Site timezone setting might do this, but not the company setting. Frustrating this is even something to hassle with try to figure out every time the clocks change and then you end up messing something else up. I’ll just deal with a broken schedule and fix it every time.
1 Like
They didn’t enter a case when I called in but it appears to have been reported as a defect in PRB0189581
1 Like
I can’t clearly say.
We have users in other time zones, but they use Remote Desktop Apps to access E10.
Maybe a new thread is need to discuss the various aspects of the “system time”
- Server location timezone vs users time zones
- Clients running in different local timezones,
- etc …
1 Like
Yea, it can get confusing quick when there isn’t really any documentation explaining it. Unless there is a doc out there explaining how to correctly handle time zones in Epicor and setup scenarios, that would be very helpful to understand this.
2 Likes
case # PRB0203283
1 Like
Thanks Kimberly. I had a ticket open as well which ended up with the same result, no surprise there. Just one more voice they have to ignore on this particular topic I suppose.
2 Likes
I kind of understand why they do what they do. Schedules (of the non-interval kind) are primarily date based. You choose what days of the week or month to run. After it runs, it does the basic math of adding some whole number of days to the last run date and time.
The time each schedule runs is almost like an after thought. It’s only set by the Next Run Time. They need to make the Schedule have a field for the desired run time too.
1 Like
Fair enough. I’m surprised that this is still an issue as it appears it was originally reported back in 10.0 or 10.1, but I may be misinterpreting the information in the Problem ticket. That being said, I do understand that this is a relatively small issue by comparison to most others that we deal with and my intention wasn’t to slam Support or Dev.
2 Likes