Sure.
I don’t know why the schedule number is so large for two of the schedules. I can’t guarantee that I didn’t reuse the Daily at 3:00AM schedule that came over from the conversion, and create new one for the other two.
It looks like none of your schedules are set to run on Sunday, which is probably why it worked for you. They need to fix this so it works for tasks that do run ON the day of the time change.
1 Like
You might be right about running on Sunday being the problem (or the solution!). I just checked our old 10.2.700 schedules, and they were set to run 7 days a week, and I always had to manually adjust the time after DST change.
UGH !! they still haven’t gotten this right. I remember the nightmares of dealing with schedules getting off an hour. I would have to go in a fix them. It was a pain.
I think that is because unlike others you have fresh new installation with the fix applied.
I was wondering that too @Olga. Is the only way to test this is to delete a schedule and redo it, then wait for the fall time change?
I did the same thing… hoping I’d come in Monday and all would be well in the Epicor schedules… Not!
1 Like
I had setup a couple new schedules about a week before DST for a new project. The times on those were still off an hour. So don’t think it matters if they are old or new schedules.
1 Like
The next run is calculated when the task is executing. So as I wrote above if you create a task and run a month before the time change, it should show the next run, after the time change, correctly, if the fix is there.
1 Like
Are you saying that two customers who are both in the public cloud are running different versions of the software? That doesn’t seem right.
I’m one behind you most likely…Flex. 2023.2.11
Ok flex excluded though.
