FYI - Daylight saving time ended

OH… one time, I purchased a clock from Radio Shack… I thought it was really cool that it had an Automatic feature (non-switchable) to change Daylight Savings time. The clock had both Time and Date, and had a preset value for when DST started/stopped… That was all really cool UNTIL US Government decided to change the date that DST Started and stopped… the clock was always messed up in the October/March.

3 Likes

Somewhere in the UP in Michigan…

I was thinking of Indiana. Prior to 2006, the state ignored DST, but some localities did. In 2006 the state passed a law to make DST state-wide.

1 Like

East Chicago, IN was like that but I think they went with the rest of the State. Maybe W. Lafayette, IN. too. I seem to recall my brother saying they didn’t switch at Purdue. But I will leave the Indiana inside info to @ERPSysAdmin. :wink:

3 Likes

Honestly, in today’s age, why? Why do we still do this to ourselves?

2 Likes

:weary: Argh, all of this talk of DST is making me ill… :nauseated_face: :face_vomiting: I lived most of my life here in Indiana not having to change our clocks and it was AMAZE-BALLS!!! Now that we have to change our clocks I long for the “good ole days” again. :sob: There was talk of changing it back but it hasn’t happened yet. I think we should. I really don’t think DST makes any difference and doesn’t help anyone save time or money.

Why can’t Epicor just look at the Server time and run Schedules off of that? The server time changes automatically and I never have to adjust it or my Windows Task Scheduler processes twice a year. And if you are running a schedule for Germany wouldn’t you just calculate the time that you want to run it based off of your (US) server time and as long as Epicor keeps with the Server time, the Schedule will continue to run at the correct time. Or am I just being too simplistic?

Anyone submit something to Epicor Ideas yet?

4 Likes

Oh my dear friend, if your server was in the Western Time Zone, people would be complaining that they had to “constantly convert the time” let alone ask them to do time math any time they scheduled to run something.

I guess the one good thing about Time Zones is that Dolly Parton’s song wouldn’t be, “Working 14 to 22, Just tryin’ to make a living…”

3 Likes

What would you submit? The only thing I can think of is adding the time zone to the schedule and let the individual Task Agent running it calculate the time to run based on the location of that particular Task Agent - since you can have up to three, on different servers, each possibly in a different time zone.

I think the solution is to make the “time to run”, a field in the schedule record. Right now it just uses the time portion of the NextRunOn field, adding however much “time” the schedules interval is for.

If a schedule is like:

image

When that runs at 12:01 AM on 11/03/2020 (2020-11-03Z05:01:00 in UTC), it just adds 1 day to set the next run time to 2020-11-04Z05:01:00. But if the DST ended after the the NextRunOn is set, the NextRunOn value of 2020-11-04Z05:01:00 represents 11:01 PM on 11/03/2020.

Had the task agent added 1 day to the date, and used the same time, it would have done:
(11/03/2020 + 1 day) + 12:00:00

That would have resulted in 12:01 AM on 11/04/2020.

I don’t think there’s a good technical solution. Everyone would be complain when there tasks didn’t run because they were scheduled between 2AM and 3AM, and complain about the tasks that didn’t run at the “right” 1:30 AM. (Is the first 1:30AM or the second 1:30AM the right one?)

The real solution…

Get rid of DST!!! :grinning:

On a more practical note. When you submit and document your schedules make sure they will work with or without DST. Also I think SQL agent deals with DST completely different so keep that in mind.

4 Likes

Tom Scott did a great Computerphile video on time zones that really emphasizes how difficult a problem this is…:

Honestly, I think it’s a miracle that scheduling works as well as it does; I really can’t complain about having to do a 2 minute Epicor maintenance task twice a year.

Consider this: if a user came to you with a problem that could take months and thousands of dollars to code a working solution - with the goal of saving one person 5 minutes a year - what would you tell them?

5 Likes

I see your argument here. If this was the case, at least address the issue in the help (and maybe even on the screen) that TimeZones and DST will affect the actual run time.

AND THIS is one of the reasons I never schedule anything to run at Midnight… I typically schedule things to run either before or after… prefer running after 2:00 AM just to try to hid anything from getting confused in time/date stamps.

3 Likes

Completely agree. If Epicor was more upfront about it, it would probably nix a lot of the frustration.

I agree it would be nice to have clear definition as to what will happen, but I’ve never seen a program tell you what will happen when DST starts or ends. The forms for IT people are probably complaining about WIndows Task Scheduler, the SQL people are complaining about SQL task agents, and payroll people are complaining about not knowing which 1:30AM the person clocked out at.

1 Like

IF the schedule included the Time Zone, there COULD be a check box to adjust for DST. Once armed with the time zone, the dates of DST are known and a process could run and reschedule as needed. Maybe? :man_shrugging:

I still do though.
In fact I’m one of “those” people who really would like to see the elimination of daylight savings… some day, I know it will probably never happen and there are much bigger issues to be concerned with but… it’s just one of my pet peeves.

3 Likes

I would tell them I need it now :wink:.

This really is a solved problem, its just that Epicor implemented scheduling poorly (one could argue incorrectly). Our network switches and routers handle DST flawlessly. My car handles DST flawlessly. Windows Task Scheduler handles DST flawlessly. In fact every IT system that I work with across several companies and plants handles DST flawlessly. The only place I have any issue with DST is with Epicor.

Like Calvin said:

Right now it just uses the time portion of the NextRunOn field, adding however much “time” the schedules interval is for.

That is the root issue. None of our other scheduled systems operate this way (adding intervals) because it would obviously cause problems with time changes. They all use the actual local system time and execute when [system time = scheduled time]. It is super simple and would be a very easy fix for Epicor. End users shouldn’t have to write custom code just to get software on their system to recognize the time of the local operating system.

4 Likes

If anyone likes the idea “Fix DST scheduling”, please drop a vote on it here:
https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-3301

1 Like