dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
932

StuartMW
Premium Member
join:2000-08-06

StuartMW

Premium Member

MSE, DST and scheduled scans

I have MSE configured to run a scheduled scan at 1am every night. With the changeover to summer time , yesterday, the scan ran at 2am instead (i.e. 1am standard time) last night. I changed the schedule to another time and changed it back to 1am so I'll see tonight if it runs at the scheduled time. BTW it did this on two machines.

MSE version is 4.2.223.0

jaykaykay
4 Ever Young
MVM
join:2000-04-13
USA

jaykaykay

MVM

What am I missing here? Why shouldn't the scan run an hour off schedule if you hadn't changed it prior to its running and after daylight time had changed? I would think that there are many programs that run, according to time, that need to be changed, not just MSE, if one is changing time. Fortunately, we don't, so nothing to think about here. But what did I miss? Are you just trying to remind everyone or what?

StuartMW
Premium Member
join:2000-08-06

1 edit

StuartMW

Premium Member

Well I've asked it to scan at 1am so that's what I expect it to do regardless of DST. Think of it just like an alarm clock. You don't reset those at the time changes.

My satellite TV receiver used to shift scheduled tasks by an hour every time DST came into or went out of effect. Unless you manually changed them you'd miss programs (which run at local times). Presumably many complained because it no longer does this.

Scheduled tasks (I used to work for a company that sold equipment that did this) are tricky when it comes to time changes. For example when springing forward the time goes from 1:59am to 3:00am. What do you do if something is scheduled at 2am? Likewise in the fall there are two 1am's (time goes from 1:59am to 1:00am).

Blackbird
Built for Speed
Premium Member
join:2005-01-14
Fort Wayne, IN

Blackbird to StuartMW

Premium Member

to StuartMW
To add to the confusion, I had exactly the opposite situation as you did. I have a short file backup program (~8 minutes run time) that is set to automatically run daily at 2:30am. It ran at 2:30 every day of the week prior to the Sunday-morning 2am time change, but Sunday morning it's logged as running at 1:30am. This morning (Monday) it again ran at 2:30am.

One has to love the perfect consistency, repeatability, and logic of digital technology. Maybe someday I'll be blessed to actually see it...

La Luna
Fly With The Angels My Beloved Son Chris
Premium Member
join:2001-07-12
New Port Richey, FL

La Luna to StuartMW

Premium Member

to StuartMW
My MSE scan ran at 3:15AM instead of 2AM? Is that the start time or the finish time?

Doesn't matter to me, it's the only thing that runs at those times anyway.

StuartMW
Premium Member
join:2000-08-06

StuartMW

Premium Member

said by La Luna:

Is that the start time or the finish time?

Start time. Also MSE randomizes the actual start time. Note that the schedule time says "Around".

I consider this schedule time-shift a MSE bug although not a serious one.
StuartMW

StuartMW to Blackbird

Premium Member

to Blackbird
said by Blackbird:

To add to the confusion...

quote:
Time is an illusion. Lunch time doubly so.

Douglas Adams

Douglas Adams would've been 61 today.

La Luna
Fly With The Angels My Beloved Son Chris
Premium Member
join:2001-07-12
New Port Richey, FL

La Luna to StuartMW

Premium Member

to StuartMW
Yep, you'd think it would be aware of the DST change. I guess it isn't.

jimkyle
Btrieve Guy
Premium Member
join:2002-10-20
Oklahoma City, OK

jimkyle to StuartMW

Premium Member

to StuartMW
If it actually did run at 1 a.m., that was an hour before the time change. If your system keeps "universal" time on the RTC and the o/s automatically corrects that to your local time zone for display (as many of them do), then it would show in the log as 1 a.m. until the time change cut in, and then would show as 2 a.m. -- as it did. I suspect this is simply a problem in understanding what's going on behind the curtain.

Of course that doesn't explain some of the other reports in this thread...
dave
Premium Member
join:2000-05-04
not in ohio

dave

Premium Member

I understood the OP to say that it ran at the wrong time in the early hours of Monday morning ("2am last night" being what I would call "2am today"), in which case the time change a day previously would not have caused the effect in the way you describe it.

But maybe I misunderstood when "2am last night" was.

StuartMW
Premium Member
join:2000-08-06

StuartMW

Premium Member

It ran around 2am Monday March 11th 2013. Hopefully that is unambiguous. That is one day after DST went into effect.

Windows (for a decade or more) has used UTC time internally. Displayed timestamps, for files etc, are calculated using your timezone and DST from the UTC base. That's why file timestamps change if you change timezones or at DST transitions.

That said, and I used the alarm clock analogy above, a scheduled event should run at the designated time. If I set my alarm clock to go off at 6:00am it does regardless of DST (assuming I adjusted the time).
dave
Premium Member
join:2000-05-04
not in ohio

dave

Premium Member

Oh, I agree. And in any case, while I know that an absolute date-and-time is stored in UTC (as a number of 100nS ticks from 1601), it's unclear to me how something like "2 AM" could be represented as UTC or not-UTC.

I mean, it's sensible to store is as "2 hours worth of time units" but not as far as I can see sensible to store it as something like "7 hours worth of time units".

I checked MSE on the Win7 system I am using here. It's configured to run at 2:00 AM, "last scan ran at 3:54 AM". Maybe I have the same disease.

StuartMW
Premium Member
join:2000-08-06

1 edit

StuartMW

Premium Member

said by dave:

...it's unclear to me how something like "2 AM" could be represented as UTC or not-UTC.

My guess it that MSE stores a UTC timestamp for it's schedule when set. Thereafter when the schedule runs it adds 24 hrs (+/- a randomization) to that value. That would explain the behavior we're seeing.

PS: From a programming standpoint this is really easy to implement. It's also very easy to check when to run.

• Get system UTC time.
• Get next run time (in UTC).
• Is run time >= system time run.
• If yes, add 24hrs to system time and save as next run time then run a scan.

This methodology gets around timezone/DST change issues since its based on elapsed time. The disadvantage is that stuff may run at a different local time.
StuartMW

StuartMW

Premium Member

FYI changing the scan time and setting it back did the trick. MSE scanned around 1am last night.