You got my vote sir and so did @aaronssh’s Epicor Idea.
I see in 2022.2 there is a time zone selection available right in the system agent task schedule, does that not fix this issue?
OO, it might, we’re moving to 2022.2.x in about a week!
There is a Time Zone selection, but the time is still off an hour when Daylight Saving Time changes.
1 Like
I’m out of votes, so I commented to the idea. Hopefully that counts for something! Seems like something easy to implement.
1 Like
I think its not easy because its a flawed design to begin with as been discussed previously. That makes it very hard to fix it.
I actually moved one of my votes to this idea and took it away from another idea.
Are you 100% sure about that? Asking because Epicor Support is trying to tell me that:
This issue has been addressed as of Kinetic 2022.1. Please find the following kbase article for your review.
I trust you more than I trust Epicor support, just looking to double-check which is true.
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?..