We’ve been on 22.2 since January. We have task schedules for multiple timezones, using that feature. All of them were off by 1 hour after the DST change.
2 Likes
Did you report it to support? I’m wondering if it would FINALLY be accepted for the bug that it is if you reported on this version.
Ok, thank you for confirming. Yes, PLEASE report it. I am not on that version yet so Epicor Support is insisting that it will be fixed if I just upgrade.
First sorry about that Andrew. I have a love hate relationship when dealing with time zones that goes back to the mid 90’s and how .net 2 handled serializing dates and time zones across the wire.
Anyway a quick question: You mention they are off by 1 now. My question: is it they were off by one on the first scheduled time after the switch or that they stayed off by one until you fix it. We’ll get it either way but I’m curious because it would point to the source of the issue.
Also is this just on time intervals or does it include scheduels such as run every thursday at 8:00 PM?
1 Like
We’re on 2022.2.8, and our scheduled tasks were off by an hour as well. This includes tasks that ran once after the DST shift (5am schedule)… I fixed LIVE, but our pilot environment still shows the difference:
Per the KB, it looks like we’d need to change the time zone for every schedule from (UTC-05:00) Eastern Time (US & Canada) to (UTC-06:00) Central Time (US & Canada). This changes the 4pm one that next run went to 5pm, back to 4pm after DST. Note: It’s not changing the time zone to UTC-4, which is what would make sense to me, but I’m sure makes sense if I did the math between server time, UTC, and local time.
Changing 20 schedule’s time zones to something that’s fake (Central time when we’re on Eastern) individually is almost as much work as correcting the next-run time for all of them. I think there should be a DST box checked somewhere in Company or Site Configuration, and having it happen automatically, like every other bit of tech today. Include Start/End dates if the world has different DST dates for countries.
1 Like
Hi Patrick,
For interval schedules, it isn’t really noticeable. We have a task that runs hourly, for example. Being off by one hour at DST change is going to have no real effect. It corrects itself either immediately, or after the next run.
The schedules that are daily at a specific time are the ones that were affected. For example, we run tasks daily at 4:30am in two different time zones (Central and Pacific). When we checked them on the Monday after the DST change, they were running at 5:30am in both timezones. They were incorrect for multiple runs over the weekend until we manually fixed them.
This was on Kinetic v2022.2.12
The NextRunOn Date/Time stored in the SysAgentSched table is stored as a UTC time, which is not affected by Daylight Saving Time.
Since UTC is not affected by Daylight Saving Time, the Agent Schedule’s local time will be ‘off’ by one hour upon DST change, because the UTC offset changes by one hour.
For example,
4:30am CST (UTC-6) = 10:30am UTC (which is what was stored in our SysAgentSched record prior to DST)
4:30am CDT (UTC-5) = 09:30am UTC (which is now what is in SysAgentSched, after manually updating)
It seems like maybe the DateTime stored in the SysAgentSched should actually be the desired local time (with timezone). The Task Agent could then calculate the UTC time from the local time and the specified timezone, and compare to the current UTC time to determine if a task needs to be run.
1 Like
Exactly.
It would be like if your alarm clock next to your bed stored the alarm time in UTC, and your clock automatically adjusted the displayed for DST. When you set the alarm for 7 AM, you want it to be relative to the time displayed, not some absolute UTC time.
1 Like
Somewhat related I just ran into this one.
I have a task scheduled for M-F @ 9PM (EST) it runs (according to SysTask table) at 2AM (next day GMT)
Works great except the Friday task has apparently never ran… because… when you ask Epicor what Day of the Week is it at 2AM GMT (9 PM EST) on Friday it says… It’s Saturday (2AM) 
Laugh all you want @andrew.johnson mean while I’m over here like
how do I fix this… Current solution is Check the Saturday box too and burry my head in the sand
sigh 
By that logic, is it running on Sunday at 9PM because you have Monday checked?
No it runs on Monday at 9 PM (which is Tuesday at 2 AM GMT) but since its scheduled to Run on Tuesday it works fine.
Mind you its running when it should, except on Fridays because whew it checks the “Day” it says Saturday (instead of Friday)
| Scheduled (EST) | Runs (EST) Actual | Equivalent (GMT) Actual | Scheduled Day of Week | Runs Day of Week (GMT) | Effect |
|---|---|---|---|---|---|
| 9 PM Monday | 9 PM Monday | 2 AM Tuesday | Monday | Tuesday |
 Works fine because it is scheduled to run on Tuesday too. Runs as Expected |
| 9 PM Tuesday | 9 PM Tuesday | 2 AM Wednesday | Tuesday | Wednesday |
Works fine because it is scheduled to run on Wednesday too. Runs as Expected |
| 9 PM Wednesday | 9 PM Wednesday | 2 AM Thursday | Wednesday | Thursday |
Works fine because it is scheduled to run on Thursday too. Runs as Expected |
| 9 PM Thursday | 9 PM Thursday | 2 AM Friday | Thursday | Friday |
Works fine because it is scheduled to run on Friday too. Runs as Expected |
| 9 PM Friday | 9 PM Friday | 2 AM Saturday | Friday | Saturday |
 Does not run because when it checks "What day is it " It says GMT (Saturday) which is not a day this task is scheduled. |
Build your own scheduler?..
Just because we can! ……
We’ll base it off of how many PartTran records have elapsed since X timeframe.
Tell you what you work on the UX and I’ll re-write the agent! Deal?
Way ahead of you.
1 Like
Come on guys, let’s get more votes on this " Fix issue with DST and Scheduled Tasks" https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-3301
This actually might be what happened to us with MRP. In order to have a couple of them run Monday-Thursday I have to check the boxes Tuesday-Friday. (times it is set to run is 6:30 CST and another one at 8:30pm CST.
I just noticed the one scheduled for 6:30 stopped running on Monday, so it looks like with the time change it no longer sees it as the next day anymore.
Guess that is one more thing I get the change when the time changes 
1 Like