I feel your pain too. Schedules are global, so if you have a plant in PA and one in Colorado (which we do), any thing scheduled for 5:00 PM in PA, already happens at a different time for the folks in Colorado.
1 Like
All of our schedules changed too. I agree 100% with what KWhite has posted. This is really confusing and unnecessary.
1 Like
So is it correct to say that in some version after 10.1.400, that schedules are DST aware?
If so, which version?
And is that automatic based on the timezone selected?
I discovered another interesting twist on this. We had a power outage overnight when the time was actually changing. When we booted back up and I ran the same query against the Ice.SysAgentSched table, the NextRunOn field was blinking zeroes.
To add to @aidacraâs post about the time being UTC, itâs not just at the SQL level.
A BAQ of SysAgentSched returns values in UTC. They are not adjusted to local time of the server or client.
All three of these DateTimes are equal
2 Likes
I opened a ticket and they babbled on about the change to UTC and such. I donât think they graps what is really happening. I donât agree that schedules should be touched. This would have really caused me issues. I recommend anyone that has the same concerns or issues to open a ticket. The more they get the more they will see out issues. They did open a problem ticket with Developement
1 Like
The desired resolution should be to add a âDaylight Saving Time Awareâ checkbox to the schedule.
If it is checked, then the system agent checks the selected time zone to see if it participates in DST. If it does, then set the âNext Runâ based on DST.
But be prepared for the tasks to get skipped in the fall, or run twice in the spring, if scheduled to run between 1:00 AM and 3:00 AM. 
The desired resolution should be to get rid of daylight savings time all-together (are you listening congress!). Iâve never heard anyone say that it helps them in any way. Just far fetched theories about energy consumption and farmers. People only complain about it. 
(thatâs the closest thing I could find to a pitchfork and a torch)
3 Likes
It actually does reduce energy consumption, by shifting the daylight hours to have a better overlap with when people are awake. Take Philadelphi as an example.
March 9th
- Sunrise: 6:22 AM
- Sunset: 6:00 PM
So business open after 6:00 PM must turn their lights on at 6:00 PM
On March 10th (after DST kicks in):
- Sunrise: 7:20 AM
- Sunset: 7:02 PM
So business open after 6:00 PM donât have to turn their lights on until 7:00 PM
And while there are business open at 6:00 AM, most of them are open 24/7, so no savings (or loss) is realized.
Iâve never seen a business that doesnât have their lights on all of the time.
Really? The local gas station that closes at 10 PM leaves all their lights on 24/7?
interesting article, where smarter people than me say the effect is negligible.
âThey found that a total of 1.24 terrawatts of electricity was savedâ
Thatâs 1,240 gigawatts. Thatâs enough to power 1024 time traveling Deloreans!
Hmmm⌠1024 is a nice round binary number. 2^10. So doc could choose 10 boolean variables to alter (like President Kenedy shot vs not shot), and test every combo of them, with the savings from DST. And no Libyans would need to be swindled out of their Plutonium!
2 Likes
Iâve continued to deal with this too even in 10.2.200 version. This last weekend I had to manually update each scheduled task to flip the next run time back to where it needed to be.
Hopefully they will get it taken care of soon if this many are having issues with it.
Kelly
2 Likes
Updating the schedules twice a year is actually better than trying to automate it.
I only did the automation thing as a challenge. Itâs not actually in our live company.
And Iâm not sure that Epicor thinks there is anything that needs to taken care of. I think it is âfunctioning as designedâ
I know of some Admins they set their Server Times to UTC/GMT on Windows. I think the military does too.
http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html
Which means your Task Agent will never be affected by DST or Timezone Change =)
The date times are stored in UTC, and converted to âlocalâ times in the UI.
Does the UI use the âlocalâ time of the App Server, or the Clientâs workstation?
If my AppServer is in the East, and my client is in the east, and I set a schedule to run at 5:00 AM, does a client running on the west coast see that as 5:00 AM or 2:00 AM?
If the west coast client sets a schedule for 8:00 AM, Would I see it run at 11:00 AM?
Given that the Task Agent Entry is not tied to a Company.
I just for example set My MRP Run time at 8:02pm EST⌠Then I changed my Timezone to Cairo and restarted the Client. It shows now 3:02am for me on the UI instead of 8:02pm.
So⌠my UTC offset should be different now.
So while under Cairo Timezone I put it to 8:02pm⌠Switched back to EST Timezone and logged back in and it shows⌠now 01:02PM ESTâŚ
So when Setting it the value it uses the Users âComputerâ Timezone, same for Display.
1 Like
Now if a user in Cairo was using a remote desktop to the App Server âŚ