Don’t forget to update the Next Run Time on your SysAgent schedules!
And it’s not just the date that might be off. A schedule I setup to run at 12:01 on the first of the month, was previously set to run at 12:01 AM on 12/1/2020, changed to 11:01 PM on 11/30/2020. So check the dates too!
Yes!
One would think Epicor could handle this better…
I thought I came across a post on the forum at one point stating that there is a property you could set to take care of this.
Not without a lot of complaints. Most people “solve” it instead of issuing a Support Ticket.
Guilty… I fixed ours and didn’t put a ticket in. Guess I’m not helping getting an actual fix by doing that.
I’d bet the farm that a support ticket would result in “Working as expected, no issue.”
That statement normally requires the ticket to be escalated. Development should decide this, not support. 
You are correct: PRB0189581 is REJECTED.
Unbelievable. Not sure why they won’t fix this. It’s irritating to have to go into the task agent schedules and change them twice a year because of this bug. It’s even more irritating they say it’s a problem and then reject it without any consequence
I guess the ball is in our court. How would we want it to work?
The solution is probably different for:
This is a good read if you’re interested in Programming issues with Time Zones
How about a Checkbox to adjust for DST and Time Zone Selection in the Task Agent Schedule?
Seems pretty simple.
I made a BPM to do it automatically, But since we only have about 6 or 7 schedules defined, it’s not really an issue to manually update them.
Ii is pretty straightforward …
I don’t mind updating them either, but every so often (sometimes twice a year) I forget to do it. There are a lot more pressing enhancements I would rather see.
Which Time Zone? The one the server is in? The one that the largest site is in? If you’re remote and you schedule something, do you use the local time from the remote location? Or should it convert to the server location (where the Task Agent is)?
I would hope the Date/Time was store in UTC and then the TimeZone would define the display on the screen.
The user would define the timezone, so it would depend on what they want to see.
I believe that the problem is a worldwide problem that we have not taken into account. The “world” time doesnt change… but individual locations DO have daylight savings time… and those times change on different dates depending on the local rules. A quick review of this Wikipedia Page on Daylight Savings Time shows how complex the rules are. But even then, there are rules within rules… Within the USA, there are some states (AZ, HI) that dont follow the DST rules… and in addition, the State of Arizona USA has even more rules… the Navaho Indian reservations DOES follow USA DST rules, but the HOPI Reservation (which is INSIDE the Navaho reservation) follows Arizona standard.
The whole thing is a mess, and should be abolished IMHO.
And isn’t there a city in the mid-west that doesn’t follow DST, while the rest of the state it is in does?
Let’s say I’m in Germany and I want something to run at 00:15 CET. Leave out DST for a moment, they would see 00:15 but that would be 18:00 EST. Does the server know the time zone of the user? Is that in a session object? Do you discern that from the currently logged in plant? Can we specify the Time Zone in the Task Agent? (That could certainly help!) When do you think it would run?
Now to DST. CEDT and DST don’t change on the same weekend, so for a short period it’s -5 and then back to -6 (in the fall and the opposite in the spring. Our DST is longer)