I just noticed that the schedules don’t adjust for Daylight Savings.
I have a schedule set for 8:00 PM on Fridays (created while on Standard Time), but the schedule now shows 9:00 PM (see Pict below)
Do most of you folks adjust the schedules’ next run time in the Sys Agent Maint?
Or leave it be and tell your users to deal with it?
Calvin
What version of Epicor are you on?
For some context, when we create a system agent schedule in 10.x, the next run time set on the schedule
Is actually the UTC equivalent of the client time when it was submitted.
Whenever the timezone offset changes on the server(i.e. when daylight savings starts and ends), the execution time will be changed from the perspective of the client’s time but the process will execute at the time listed in the ice.sysagentsched table at that UTC time.
There is an enhancement request (186211) scheduled to be included in a future 10.x release that will allow a user to specify what the submitted/scheduled time on the schedule means; i.e. client time, server time or UTC time (how it behaves now).
Why would there be a discussion on what the schedule time means? In every instance, the user expects that 7:00PM is 7:00PM. Why would Epicor want to make this more complicated than it needs to be?
I like this enhancement. Our servers are in one time zone and our users are spread out among other time zones with different daylight transition dates.
Mark W.
Like @Mark_Wonsil indicated there is a very valid use case for this. Not Epicor trying to make lives harder, they are simply adding a layer of specificity that becomes more and more needed as IoT grows, remote workforces grow and SASS products grow.
We too just noticed yesterday our schedules had adjusted with the, spring
forward, time change. It messed up a scheduled BAQ export we use for customer requested reporting, the export feeds into other processes. Thanks for the explanation Nathan. I can understand the why and hopefully we’ll see the enhancement implemented soon.
You ever saw the following behavior:
If you set it to 8PM EST which is 12:00AM UTC it does as it should behind the scenes it sets the Next Run to be 1 day later at 12:00AM UTC
However, it still runs on Sunday but it should not, despite Sunday being unchecked. Assumption is a bug in logic that probably checks Date and Time separately. So it assumes “Oh the date matches Monday”.
It could also be just 12:00AM exactly; I have yet to test 8:01PM, while 7:59pm works fine.
Haso, that’s interesting. We were told there’s a bug in 10.0 with daily schedules that have some days unchecked. Now I’m wondering if that’s related to EDT time adding 4 hours to convert to UTC time, which is then on the next day (that is unchecked!). We’ll have to see if that’s the trend.
Also chiming in on this one. We are on 10.2.200.5 and just saw the shift in times for all schedules by an hour due to daylight saving. Any idea when this enhancement will be put in?
Kelly
10.2 is supposed to support multiple time zones.
Since the fields for timezones were in 10.1, and it only took about 6 years for that to be implemented, I expect you should see DST in another 5 or 6 years 
Ugggggggggggh. This needs fixed soon. I have a very small window to run some of these batches overnight and shifting an hour is no bueno.
It has been addressed in the last several releases–which release are you currently live on?
I’m running 10.2.300.8
Do you have a timezone set on your company maintenance records?
yes.
then please submit a support ticket to review.
I am glad I read this. All my schedules changed time. This never happened with E9 that I recall. it should not matter what time changes the schedules should not adjust. I want the job to run at 11:30pm if time changes it should still run at 11:30pm.
What I think happens, is the schedule is set using UTC (Coordinated Universal Time). So your scheduled task IS still running at the same time. YOU are now in a different frame of reference (being on DST).
That is CONFUSING. IT should read real time. IF the shop wants to see my schedule I would have to explain it is UTC…yeah that works, NOT.
So I just adjusted all the schedules will they be wrong? Some schedules showed correct; the ones that are for next month still showed 11:30pm; but this month moved to 12:30AM of the same day. I can’t risk them running Saturday morning instead of Saturday Night.
I don’t like this at all